DEV Community: Akanji Rahman

DUST sponsorship: How one wallet pays fees for another user's transaction

Akanji Rahman — Sat, 09 May 2026 21:09:47 +0000

DUST sponsorship: How one wallet pays fees for another user's transaction

Every transaction on Midnight consumes DUST. New users start with a DUST balance of zero, which creates a problem; how can they submit transactions if they cannot pay fees, especially the transactions needed to acquire NIGHT tokens in the first place?

DUST sponsorship solves this. A sponsor (typically a backend wallet) that already holds NIGHT tokens and has accumulated DUST covers the fee portion of another user's transaction. The user's keys sign the user's assets; the sponsor's keys sign only the DUST portion. The two halves are joined into one valid, on-chain transaction.

This tutorial walks through the complete sponsorship flow:

How tokenKindsToBalance splits fee responsibility between the user and the sponsor
A full sponsor service implementation
How DUST regenerates and depletes

Before you begin

Make sure you are comfortable with the following:

Midnight dev setup: You know how to set it up and use its basic features. View the Midnight developer tutorial.
TypeScript: You understand types, functions, and async operations.
DUST and NIGHT: You understand the basic roles of DUST and NIGHT in Midnight transactions and network operations. Read the DUST and NIGHT overview.

Understanding DUST

A common mistake is treating DUST as a token. You cannot buy it on an exchange or send it between addresses. DUST is a shielded resource that:

Accumulates continuously while you hold NIGHT tokens
Gets consumed each time you submit a transaction that requires fees
Decays over approximately one week if you move your NIGHT tokens away
Cannot be transferred directly from one address to another. The sponsorship flow described in this tutorial is the only mechanism to pay fees on behalf of another wallet

The key parameters on the Preview network are:

Parameter	Value	What it means
`night_dust_ratio`	5,000,000,000	Maximum of 5 DUST per NIGHT held
`generation_decay_rate`	8,267	Approximately one week to generate from zero to maximum, or decay from maximum to zero
`dust_grace_period`	3 hours	Timestamp tolerance window that allows back-dated DUST spends within 3 hours of the current block time

Each wallet has three distinct addresses: a shielded address, an unshielded address, and a DUST address. The DUST address starts empty. Transactions cannot proceed until DUST is present or a sponsor covers the fees.

How sponsorship works

Sponsorship splits the transaction balancing process into two scoped operations:

The user balances their own shielded and unshielded token inputs, explicitly excluding DUST.
The sponsor takes the user's partially balanced transaction and adds DUST fees from their own DUST balance.

The sponsor then submits the fully balanced transaction to the network. The tokenKindsToBalance parameter makes this split possible: it controls which resource type each party handles.

The user balances without DUST

Call balanceUnboundTransaction on the user's wallet, excluding 'dust' from tokenKindsToBalance.

// user-side.ts

import { WalletFacade } from "@midnight-ntwrk/wallet-sdk-facade";
import type { UnboundTransaction } from "@midnight-ntwrk/ledger-v8";

async function prepareUserTransaction(
  userWallet: WalletFacade,
  transaction: UnboundTransaction, // built from your contract call or transfer intent
  userShieldedKeys: Uint8Array[],
  userDustKey: Uint8Array,
  userKeystore: { signData: (payload: Uint8Array) => Promise<Uint8Array> }
) {
  const userRecipe = await userWallet.balanceUnboundTransaction(
    transaction,
    {
      shieldedSecretKeys: userShieldedKeys,
      dustSecretKey: userDustKey,
    },
    {
      ttl: new Date(Date.now() + 30 * 60 * 1000), // 30-minute TTL
      tokenKindsToBalance: ["shielded", "unshielded"], // 'dust' deliberately omitted
    }
  );

  const userSigned = await userWallet.signRecipe(userRecipe, (payload) =>
    userKeystore.signData(payload)
  );

  return await userWallet.finalizeRecipe(userSigned);
}

The SDK processes shielded and unshielded inputs but leaves the fee slot unpopulated (this is intentional). signRecipe and finalizeRecipe seal the user's cryptographic commitments into a serialisable object. Once sealed, neither the sponsor nor any other party can alter the asset portion without invalidating those commitments. The 30-minute TTL applies to the entire flow: if the sponsor does not submit within that window, the network rejects the transaction. Pass the return value of finalizeRecipe to your sponsor service as the userFinalized payload.

Note: You still need to pass dustSecretKey even though 'dust' is excluded from tokenKindsToBalance. The SDK requires it for internal bookkeeping and fee estimation. Excluding 'dust' from tokenKindsToBalance prevents it from attempting to draw from an empty balance.

The sponsor adds DUST fees

Call balanceFinalizedTransaction on the sponsor's wallet, restricting tokenKindsToBalance to ['dust'].

// sponsor-side.ts

import { WalletFacade } from "@midnight-ntwrk/wallet-sdk-facade";
import type { FinalizedTransaction } from "@midnight-ntwrk/ledger-v8";

async function sponsorTransaction(
  sponsorWallet: WalletFacade,
  sponsorShieldedKeys: Uint8Array[],
  sponsorDustKey: Uint8Array,
  sponsorKeystore: { signData: (payload: Uint8Array) => Promise<Uint8Array> },
  userFinalized: FinalizedTransaction // received from the user via API
) {
  const sponsorRecipe = await sponsorWallet.balanceFinalizedTransaction(
    userFinalized,
    {
      shieldedSecretKeys: sponsorShieldedKeys,
      dustSecretKey: sponsorDustKey,
    },
    {
      ttl: new Date(Date.now() + 30 * 60 * 1000),
      tokenKindsToBalance: ["dust"], // sponsor handles DUST only
    }
  );

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

  const sponsorFinalized = await sponsorWallet.finalizeRecipe(sponsorSigned);
  return await sponsorWallet.submitTransaction(sponsorFinalized);
}

balanceFinalizedTransaction receives a transaction that already carries the user's zero-knowledge proofs and asset commitments; it adds DUST inputs on top without touching the existing proof data. Restricting tokenKindsToBalance to ['dust'] is not optional; including 'shielded' or 'unshielded' would attempt to re-balance inputs the user already committed, causing a double-spending error. The signRecipe → finalizeRecipe → submitTransaction chain seals the sponsor's DUST contribution and broadcasts the transaction as a single atomic operation. The network sees one transaction, not two.

How sponsorship preserves proof identity

A common concern is whether the sponsor's key ends up attached to the user's transaction. It does not.

Each party generates zero-knowledge proofs only for their own part of the transaction. The user's proofs are generated locally, using the user's own keys, before userFinalized leaves the client. By the time the sponsor receives it, those proofs are cryptographically sealed: signRecipe and finalizeRecipe lock the user's asset commitments so that no third party can alter or re-sign them without invalidating the entire proof. The sponsor generates a separate proof covering only the DUST spend, signed with the sponsor's own key.

If your Compact smart contract calls ownPublicKey(); a circuit witness function that returns the public key of whoever is running the proof locally, it will always resolve to the user's key, not the sponsor's. The sponsor never touches the user's circuit execution. The final on-chain transaction carries two distinct cryptographic domains: the user's asset proofs attributed to the user's key, and the sponsor's DUST proof attributed to the sponsor's key. Privacy is preserved for both parties.

Full sponsor service implementation

Wire the wallet lifecycle, the sponsorship endpoint, rate limiting, and DUST monitoring into a single Express application.

// sponsor-service.ts

import express from "express";
import * as bip39 from "bip39";
import * as ledger from "@midnight-ntwrk/ledger-v8";
import {
  WalletFacade,
  type DefaultConfiguration,
} from "@midnight-ntwrk/wallet-sdk-facade";
import { ShieldedWallet } from "@midnight-ntwrk/wallet-sdk-shielded";
import { DustWallet } from "@midnight-ntwrk/wallet-sdk-dust-wallet";
import {
  UnshieldedWallet,
  createKeystore,
  PublicKey,
  InMemoryTransactionHistoryStorage,
} from "@midnight-ntwrk/wallet-sdk-unshielded-wallet";
import {
  HDWallet,
  Roles,
  type AccountKey,
} from "@midnight-ntwrk/wallet-sdk-hd";
import { Buffer } from "buffer";

const app = express();
app.use(express.json({ limit: "2mb" }));

let sponsorWallet: WalletFacade | null = null;
let sponsorShieldedKeys: Uint8Array[] = [];
let sponsorDustKey: Uint8Array;
let sponsorKeystore: {
  signData: (payload: Uint8Array) => Promise<Uint8Array>;
};

function deriveRoleKey(
  accountKey: AccountKey,
  role: number,
  index = 0
): Buffer {
  const result = accountKey.selectRole(role).deriveKeyAt(index);
  if (result.type === "keyDerived") return Buffer.from(result.key);
  return deriveRoleKey(accountKey, role, index + 1);
}

async function initSponsorWallet() {
  const seedPhrase = process.env.SPONSOR_SEED_PHRASE;
  if (!seedPhrase) throw new Error("SPONSOR_SEED_PHRASE is required");

  const networkId = process.env.NETWORK_ID ?? "preview";
  const rpcUrl = process.env.RPC_URL ?? "wss://rpc.midnight.network";
  const indexerUrl =
    process.env.INDEXER_URL ?? "https://indexer.midnight.network";
  const proofServerUrl =
    process.env.PROOF_SERVER_URL ?? "http://localhost:6300";

  const seed = bip39.mnemonicToSeedSync(seedPhrase);
  const hdWallet = HDWallet.fromSeed(seed);
  if (hdWallet.type !== "seedOk")
    throw new Error("Failed to derive keys from seed phrase");

  const account = hdWallet.hdWallet.selectAccount(0);
  const shieldedSeed = deriveRoleKey(account, Roles.Zswap);
  const dustSeed = deriveRoleKey(account, Roles.Dust);
  const unshieldedKey = deriveRoleKey(account, Roles.NightExternal);
  hdWallet.hdWallet.clear();

  const shieldedKeys = ledger.ZswapSecretKeys.fromSeed(shieldedSeed);
  const dustKey = ledger.DustSecretKey.fromSeed(dustSeed);
  const unshieldedKeystore = createKeystore(unshieldedKey, networkId);

  const configuration: DefaultConfiguration = {
    networkId,
    costParameters: { feeBlocksMargin: 5 },
    relayURL: new URL(rpcUrl),
    provingServerUrl: new URL(proofServerUrl),
    indexerClientConnection: {
      indexerHttpUrl: `${indexerUrl}/api/v4/graphql`,
      indexerWsUrl: `${indexerUrl.replace(
        "https://",
        "wss://"
      )}/api/v4/graphql/ws`,
    },
    txHistoryStorage: new InMemoryTransactionHistoryStorage(),
  };

  sponsorWallet = await WalletFacade.init({
    configuration,
    shielded: (config) =>
      ShieldedWallet(config).startWithSecretKeys(shieldedKeys),
    unshielded: (config) =>
      UnshieldedWallet(config).startWithPublicKey(
        PublicKey.fromKeyStore(unshieldedKeystore)
      ),
    dust: (config) =>
      DustWallet(config).startWithSecretKey(
        dustKey,
        ledger.LedgerParameters.initialParameters().dust
      ),
  });

  await sponsorWallet.start(shieldedKeys, dustKey);

  sponsorShieldedKeys = shieldedKeys as unknown as Uint8Array[];
  sponsorDustKey = dustKey as unknown as Uint8Array;
  sponsorKeystore = unshieldedKeystore;

  const state = await sponsorWallet.waitForSyncedState();
  console.log("Sponsor wallet initialized");
  console.log("Sponsor DUST address:", state.dust.address);

  await checkDustLevel();
}

async function checkDustLevel() {
  if (!sponsorWallet) return;

  const state = await sponsorWallet.waitForSyncedState();
  const dustBalance = state.dust.totalCoins;
  const LOW_DUST_THRESHOLD = 100;

  if (dustBalance < LOW_DUST_THRESHOLD) {
    console.warn(
      `[WARN] Sponsor DUST balance is low: ${dustBalance}. Top up NIGHT holdings.`
    );
  } else {
    console.log(`Sponsor DUST balance: ${dustBalance}`);
  }
}

// Simple in-memory rate limiter; use Redis for production
const requestCounts = new Map<string, { count: number; resetAt: number }>();
const RATE_LIMIT = 10;
const RATE_WINDOW_MS = 60_000;

function isRateLimited(ip: string): boolean {
  const now = Date.now();
  const entry = requestCounts.get(ip);

  if (!entry || now > entry.resetAt) {
    requestCounts.set(ip, { count: 1, resetAt: now + RATE_WINDOW_MS });
    return false;
  }

  entry.count += 1;
  return entry.count > RATE_LIMIT;
}

const processedTxIds = new Set<string>();

app.post("/sponsor", async (req, res) => {
  const clientIp = req.ip ?? "unknown";

  if (isRateLimited(clientIp)) {
    return res
      .status(429)
      .json({ success: false, error: "Rate limit exceeded" });
  }

  const { userFinalized, idempotencyKey } = req.body;

  if (!userFinalized) {
    return res
      .status(400)
      .json({ success: false, error: "Missing userFinalized" });
  }

  if (idempotencyKey && processedTxIds.has(idempotencyKey)) {
    return res
      .status(200)
      .json({ success: true, message: "Already processed" });
  }

  if (!sponsorWallet) {
    return res
      .status(503)
      .json({ success: false, error: "Sponsor wallet not ready" });
  }

  try {
    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);
    const txHash = await sponsorWallet.submitTransaction(sponsorFinalized);

    if (idempotencyKey) processedTxIds.add(idempotencyKey);

    console.log(`Sponsored transaction submitted: ${txHash}`);
    await checkDustLevel();

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

app.get("/health", async (_req, res) => {
  if (!sponsorWallet) {
    return res.status(503).json({ status: "not ready" });
  }

  const state = await sponsorWallet.waitForSyncedState();
  return res.json({ status: "ok", dustBalance: state.dust.totalCoins });
});

const PORT = parseInt(process.env.PORT ?? "3001", 10);

initSponsorWallet()
  .then(() => {
    app.listen(PORT, () =>
      console.log(`Sponsor service running on port ${PORT}`)
    );
  })
  .catch((err) => {
    console.error("Failed to initialize sponsor wallet:", err);
    process.exit(1);
  });

HDWallet.fromSeed() derives three independent key sets from a single mnemonic using BIP-44 role paths. hdWallet.clear() is called immediately after to prevent the master seed from remaining in memory. WalletFacade.init() starts all three sub-wallets against the same network configuration, and start() triggers chain synchronisation. waitForSyncedState() then blocks until the wallet has caught up before the service begins accepting requests. The in-memory rate limiter and idempotency set are sufficient for a single-instance deployment. Replace both with Redis before running at scale. DUST balance is checked after every successful sponsorship so the service warns before the wallet runs dry rather than discovering the problem mid-request.

Environment variables

Set these environment variables before starting the service.

SPONSOR_SEED_PHRASE="your twelve word seed phrase here"
NETWORK_ID="preview"
RPC_URL="wss://rpc.midnight.network"
INDEXER_URL="https://indexer.midnight.network"
PROOF_SERVER_URL="http://localhost:6300"
PORT="3001"

NETWORK_ID must be the string identifier ('preview' or 'preprod'), not a number, because WalletFacade uses it for address encoding and network routing. RPC_URL requires a WebSocket URL (wss://
...

Selective Disclosure Patterns in Compact

Akanji Rahman — Sun, 03 May 2026 05:17:35 +0000

Nowadays blockchains treat privacy like it's just an extra. Just an additional feature. Everything is visible and public. This architecture works for systems where public transparency is the end goal. But what happens when you begin to handle big data, medical records or sensitive information? It collapses. Full transparency and accountability is not a feature in these contexts, it's a problem.

How does Midnight solve this problem?
Understanding the privacy model
Using disclose() correctly
- Placing disclose() at the right scope
- Disclosure through conditional expressions
What's safe to disclose vs what leaks privacy
- Safe to disclose
- What actually leaks privacy?
Applying domain-separated hashing for cross-property unlinkability
- How does this relate to Compact?
- The round counter and linkability
Running a privacy audit on your contract
Conclusion

Prerequisites

This is an intermediate tutorial. Before reading, you should be comfortable with:

Basic Compact syntax — you understand what witness, circuit, ledger, and export declarations do. If not, start with the Compact language reference.
The Compact compiler installed — follow the installation guide to set it up.
Zero-knowledge proofs at a conceptual level — you understand that a ZK proof lets you prove a statement is true without revealing the underlying data.
Familiarity with a typed language like TypeScript — Compact's syntax is modelled on TypeScript, so comfort with typed functions, structs, and return types will help.

How does Midnight solve this problem?

Midnight implements a solution known as "Selective Disclosure". This is the ability of users to choose what information to reveal and who this information can be revealed to without revealing the full data.

For example, instead of displaying "Rahman's balance is 200,000 USDT", a Midnight DApp can publish a zero-knowledge proof that says "Rahman's balance exceeds the required threshold" and nothing more. This has solved two major issues efficiently; The sensitive data stays private and the important and verifiable fact becomes public. This is the foundation of Programmable privacy on Midnight.

This tutorial walks you through how Selective disclosure works in Compact, which is Midnight's Typescript inspired smart contract language. The knowledge you'll get from reading this article include:

a). Learning the mechanics of the disclose() operator.
b). Understanding what is safe to disclose as opposed to what silently leaks privacy.
c). Applying domain-separated hashing to block cross-property linkability.
d). Working through a privacy audit checklist you can run on your own contracts before deployment.

Understanding the privacy model

Before we get into the coding technicalities, how does Compact even work?

Every Compact Contract operates across two kinds of state. The Public State and The Private State.

The Public State: This is the data that is written to the onchain ledger which is open and visible to all network participants.
The Private State: This is the data that lives only on the user's computer and is never exposed to the network. It comes from 'witness' functions that your DApp provides locally, and from any value derived from those witness values.
The zero-knowledge proof generated by a circuit proves that the computation was performed correctly, without leaking the witness values involved. The major guarantee is that the network learns that the rule was followed, not what values were used.

Compact uses a compiler's witness protection program which is an interpreter that tracks which values contain witness data and rejects any program that would disclose sensitive data without an explicit declaration. Privacy becomes the default and disclosure is an exception you must deliberately request.

Using `disclose()` correctly

The disclose() wrapper is how you tell the Compact compiler: "I know this value contains private data, and I am intentionally making it public." Without it, the compiler stops, displaying a detailed error. Below is a simple example of this; recording a private balance on-chain:

pragma language_version >= 0.16 && <= 0.22;

import CompactStandardLibrary;

witness getBalance(): Bytes<32>;
export ledger balance: Bytes<32>;

export circuit recordBalance(): [] {
balance = disclose(getBalance());
}

If you remove the disclose() wrapper, the compiler immediately rejects the program:

Exception: selective.compact line 9 char 9:
  potential witness-value disclosure must be declared but is not:
    witness value potentially disclosed:
      the return value of witness getBalance at line 5 char 1
    nature of the disclosure:
      ledger operation might disclose the witness value
    via this path through the program:
      the right-hand side of = at line 9 char 9

The error message is precise. It names the witness function that is the source of the data, explains the nature of the disclosure, and traces the full path through the program. This is because the compiler wants you to understand exactly what you are declaring when you add the disclose() wrapper.

It is important to note that placing a disclose() wrapper does not cause disclosure in itself. It simply tells the compiler to treat the wrapped expression as if it does not contain witness data. The actual disclosure happens at the storage or return point.

disclose() is the declaration, not the action.

Placing `disclose()` at the right scope

For simple values, place disclose() as close to the storage or return point as possible. This is important because it minimizes the scope of the disclosure declaration and makes it more difficult to accidentally reuse a disclosed value in a privacy sensitive context elsewhere in the circuit.

For structured values such as tuples, vectors or structs, wrap only the field you intend to disclose:

pragma language_version >= 0.16 && <= 0.22;

import CompactStandardLibrary;

struct UserRecord {
publicName: Bytes<32>;
privateScore: Uint<64>;
}

witness getUserRecord(): UserRecord;
export ledger displayName: Bytes<32>;

export circuit publishName(): [] {
const record = getUserRecord();
// Only disclose the name field, not the entire struct
displayName = disclose(record.publicName);
}

This pattern is important because wrapping the entire struct in a single disclose() would declare the privateScore field as publicly disclosed too even though you never store it onchain. The compiler would accept it, but you would be declaring an intention that does not match your actual privacy requirements.

Disclosure through conditional expressions

The compiler also catches indirect disclosure through boolean comparisons. This is one of the most common unintentional privacy leaks in zero-knowledge contracts:

import CompactStandardLibrary;
witness getBalance(): Uint<64>;

// This will NOT compile — the comparison result leaks the witness value
export circuit balanceExceeds(n: Uint<64>): Boolean {
return getBalance() > n;
}

Exception: selective.compact line 6 char 1:
  potential witness-value disclosure must be declared but is not:
    witness value potentially disclosed:
      the return value of witness getBalance at line 2 char 1
    nature of the disclosure:
      the value returned from exported circuit balanceExceeds might disclose the result of a
      comparison involving the witness value
    via this path through the program:
      the comparison at line 6 char 8

Returning a boolean derived from a private value is still a disclosure as the result narrows the range of possible the attacker needs to test. If you intend to return this boolean, you must declare it:

import CompactStandardLibrary;
witness getBalance(): Uint<64>;

export circuit balanceExceeds(n: Uint<64>): Boolean {
return disclose(getBalance()) > n;
}

Whether this is appropriate depends on your use case. If you are building a compliance gate (e.g "balance exceeds the minimum required to participate"), returning the boolean is intentional and acceptable. If you are building a privacy-preserving wallet, returning it leaks information about the user's balance range with every call.

What's safe to disclose vs what leaks privacy

Not all disclosures are equal. Some values are safe to publish because they carry no meaningful information about the underlying private data. Others appear harmless but silently narrow the privacy guarantees your DApp advertises. So how do we differentiate them?

Safe to disclose

Derived commitments and hashes (with correct library functions).

The Compact standard library includes functions the compiler recognizes as cryptographically sound transformations. When you wrap witness data in transientCommit(), the compiler treats the output as not containing witness data, which means no explicit disclose() is required for a commitment:

import CompactStandardLibrary;

witness getSecretValue(): Field;
witness getNonce(): Field;
export ledger commitment: Field;

export circuit commitValue(): [] {
const secret = getSecretValue();
const nonce = getNonce();
// transientCommit output is treated as non-witness by the compiler
commitment = transientCommit(secret, nonce);
}

An important distinction between these four functions: the compiler treats transientCommit() output as not containing witness data, so no disclose() is required on the result. transientHash(), however, is NOT considered sufficient to protect witness data — if the input came from a witness, the output still requires disclose() before it can be stored in the ledger or returned from an exported circuit.

The transient variants (transientCommit and transientHash) are circuit-efficient but their algorithm is not guaranteed to stay consistent across network upgrades, so they should not be used to derive state data that needs to be verified later. The persistent variants (persistentCommit and persistentHash) use SHA-256 and are guaranteed to remain consistent across upgrades, so use these for any values stored in ledger state.

Aggregate results that do not reveal individual values

Storing a count of transactions or a running total where the per transaction values remain private is generally safe, provided the aggregate does not itself narrow the input range to be exploitable.

Public keys derived from private keys through domain-separated hashing

This pattern is used throughout the official examples. You derive a public identifier from a private key, publish the public identifier, and keep the private key local. Because the hash function is one-way and hard to invert, the public key reveals nothing about the private key. The section on domain-separated hashing covers this pattern in depth.

What actually leaks privacy? (even with `disclose()`)?

Raw witness values

Storing disclose(getBalance()) directly onchain publishes the balance in plaintext. This is appropriate when the value is intended to be public (e.g a display name, a transaction amount for a public ledger), but it is a complete disclosure of the underlying data.

Arithmetic on witness values

Adding, subtracting, or scaling a private value before disclosure does not hide it cryptographically. The Compact compiler correctly rejects this without a disclose() wrapper, but the real risk is developers who add disclose() and assume the arithmetic hides the value. It does not. Here's what it does:

// Dangerous — disclosing an offset balance still reveals the balance
balance = disclose(getBalance() + 73);

If an attacker knows the offset which in this case is 73, they recover the original value immediately.

Boolean outputs from comparisons on private data

Exposing true/false results of comparisons on confidential values enables progressive disclosure of sensitive information. An attacker who can call the circuit many times with different values can binary-search their way to the exact private value through repeated queries. If you must expose a threshold check, consider rate-limiting at the DApp layer and documenting the tradeoff clearly.

Enum variants derived from private logic

Returning a value that is state constant or a State enum value such as 'Pending', 'Rejected', etc that was computed from sensitive data can leak information about the data depending on the number of states that exist and how they map to the input space.

Applying domain-separated hashing for cross-property unlinkability

One of the more delicate privacy risks in zero knowledge contracts is cross-property linkability which is what occurs when two different disclosures from the same private identity can be correlated by an observer even if neither disclosure reveals the identity itself. For example, Rahman reveals two things in separate transactions: a proof that his KYC tier is "premium" and a proof that his account is over 10 months old. Each proof reveals nothing individually, but if both proofs are signed with the same public key or derived from the same hash of the Rahman's identity, an observer can link the two transactions to Rahman, reconstructing a profile without ever learning the underlying identity.

How do we resolve this? Instead of deriving a single public key from a user's secret key, you derive a different public key for each purpose (or domain) by including a domain tag in the hash input. Two hashes with different domain tags, even for the same secret, produce completely unrelated outputs.

How does this relate to Compact?

The previous examples use this pattern directly. The publicKey circuit in the lock example incorporates a domain tag as part of the hash:

pragma language_version >= 0.16 && <= 0.22;

import CompactStandardLibrary;

circuit publicKey(round: Field, sk: Bytes<32>): Bytes<32> {
return persistentHash<Vector<3, Bytes<32>>>(
[pad(32, "midnight:examples:lock:pk"), round as Bytes<32>, sk]
);
}

The string midnight:examples:lock:pk is the domain tag. It is namespaced to prevent collision with other contracts that might use the same hash function on the same secret key. This pattern can be extended across different properties of the same identity:

pragma language_version >= 0.16 && <= 0.22;

import CompactStandardLibrary;

// Produce an unlinkable key for KYC tier disclosure
circuit kycTierKey(round: Field, sk: Bytes<32>): Bytes<32> {
return persistentHash<Vector<3, Bytes<32>>>(
[pad(32, "myapp:identity:kyc-tier"), round as Bytes<32>, sk]
);
}

// Produce a separate, unlinkable key for account-age disclosure
circuit accountAgeKey(round: Field, sk: Bytes<32>): Bytes<32> {
return persistentHash<Vector<3, Bytes<32>>>(
[pad(32, "myapp:identity:account-age"), round as Bytes<32>, sk]
);
}

witness secretKey(): Bytes<32>;
export ledger kycAuthority: Bytes<32>;
export ledger ageAuthority: Bytes<32>;
export ledger round: Counter;

export circuit registerKycTier(): [] {
const sk = secretKey();
kycAuthority = disclose(kycTierKey(round.read() as Field, sk));
}

export circuit registerAccountAge(): [] {
const sk = secretKey();
ageAuthority = disclose(accountAgeKey(round.read() as Field, sk));
}

By doing this, an observer who sees both kycAuthority and ageAuthority on the ledger cannot determine whether they belong to the same user. The domain tags ensure the outputs are cryptographically unrelated, even though both were derived from the same secret key.

The round counter and linkability

The round counter in the examples above serves a second purpose. Without it, a user who calls registerKycTier() twice would produce the same kycAuthority value both times, allowing an observer to link both calls to the same identity. By introducing round into the hash, each call produces a different output even with the same secret key. The linkability between rounds is broken when round is incremented between calls.

Something to note before moving on: never reuse a nonce in a commitment scheme. If you use persistentCommit(value, nonce) and the same nonce appears onchain in double transactions, an observer can link both commitments and if they can observe one opening, potentially infer the other.

Running a privacy audit on your contract

Before you deploy a contract to a testnet or mainnet, you should go through this checklist first. It helps to identify, the most common privacy mistakes.

Privacy audit checklist

Disclosure scope

(i). Every disclose() call wraps the minimum expression necessary, not an entire struct when only one field needs to be public.
(ii). No disclose() is placed on a witness call whose output will be used in subsequent private computations. If a witness value travels both a public path and a private path, these should be two separate values.
(iii). All exported circuit return values are reviewed. If a return value is derived from witness data, confirm the disclosure is on purpose and document what information it reveals.

Boolean and comparison leaks

(i). No exported circuit returns a boolean, integer, or enum that is directly derived from an undisclosed private value without documenting the intended information disclosure.
(ii). For threshold checks (e.g. balance > n), consider whether repeated calls allow binary search over the private value. If so, document the tradeoff or implement rate limiting at the DApp layer.

Hashing and commitments

(i). transientHash/transientCommit outputs should not be used to derive ledger state that needs to persist across network upgrades. Use persistentHash/persistentCommit for those values.
(ii). Nonces used in persistentCommit are never reused. Reusing a nonce with the same value allows on-chain commitment linking.
(iii). Hash inputs do not contain values that an attacker could enumerate to reverse the hash (e.g a small integer hashed alone without a nonce).

Cross-property linkability

(i). Each distinct property of a private identity must use a separate, name-spaced domain tag in its key derivation hash.
(ii). Domain tag strings follow a consistent, collision-resistant naming convention (e.g., "firstproject:context:property").
(iii). A round counter or similar freshness mechanism is included in any public key derivation to prevent same-key linkability across multiple interactions.

Compiler verification

(i). The contract compiles cleanly without suppressed warnings. Review any disclose() wrapper you added in response to a compiler error rather than from intentional design.
(ii). After any refactor, recompile the contract from scratch and re-review all disclose() sites, structural changes can introduce new disclosure paths.

Documentation

(i). Each disclose() site is accompanied by an inline comment explaining what is being disclosed and why it is intentional.
(ii). The contract's README note or specification states clearly which fields in the ledger are public, which are derived from private data, and what information each derived field reveals.

Conclusion

Using Selective disclosure in Midnight is not just a feature, it is an architectural guarantee fused into the language. The compiler's witness protection program means you cannot accidentally publish private data without being forced to make a deliberate decision which is great for security of sensitive data.

The disclose() wrapper is that decision point, and treating it as such, rather than as a formality to satisfy the compiler, is what separates a contract with genuine privacy properties from one that only appears private.

In this tutorial we have covered the full practical arc of selective disclosure in Compact. We learned how the public/private state split works and why privacy is the default. We also learned how to use disclose() correctly, how to scope it precisely to avoid over-disclosure on structured values, and how the compiler catches indirect leaks through arithmetic and conditionals.

Domain-separated hashing was applied to break cross-property linkability, using the same pattern Midnight's own standard examples rely on. And now, there is a concrete privacy audit checklist to run against contracts before they reach the network.

If you have any questions on this article or you're confused somewhere, please engage and let me know. Share this with anyone you think it will help. Privacy is the default, disclosure is the exception.

DEV Community: Akanji Rahman

DUST sponsorship: How one wallet pays fees for another user's transaction

DUST sponsorship: How one wallet pays fees for another user's transaction

Before you begin

Understanding DUST

How sponsorship works

The user balances without DUST

The sponsor adds DUST fees

How sponsorship preserves proof identity

Full sponsor service implementation

Environment variables

Selective Disclosure Patterns in Compact

Table of contents

Prerequisites

How does Midnight solve this problem?

Understanding the privacy model

Using disclose() correctly

Placing disclose() at the right scope

Disclosure through conditional expressions

What's safe to disclose vs what leaks privacy

Safe to disclose

Aggregate results that do not reveal individual values

Public keys derived from private keys through domain-separated hashing

What actually leaks privacy? (even with disclose())?

Raw witness values

Arithmetic on witness values

Boolean outputs from comparisons on private data

Enum variants derived from private logic

Applying domain-separated hashing for cross-property unlinkability

How does this relate to Compact?

The round counter and linkability

Running a privacy audit on your contract

Privacy audit checklist

Disclosure scope

Boolean and comparison leaks

Hashing and commitments

Cross-property linkability

Compiler verification

Documentation

Conclusion

Using `disclose()` correctly

Placing `disclose()` at the right scope

What actually leaks privacy? (even with `disclose()`)?