Your Data Isn't Private. You Just Haven't Put It On-Chain Yet

There's a dangerous assumption most developers bring into Compact:

"It's a privacy-first chain. My data is private unless I explicitly expose it."

This is backwards. And it's where the serious mistakes happen.

The actual model

Compact doesn't give you automatic privacy. It gives you a hard boundary between two worlds, and a compiler that enforces it.

The boundary between them is explicit. You cross it deliberately, with a specific annotation, or you don't cross it at all. The compiler guarantees this. You cannot accidentally move private data into public state, it's a compile error, not a runtime surprise.

But here's what trips people up: the guarantee goes one direction. The compiler stops private data from leaking into public state. It does not prevent you from intentionally putting sensitive data on-chain by slapping it in export ledger and calling it a day. That's your problem to reason about.

export ledger means public. Completely.

This is the rule that doesn't have exceptions:

export ledger balance: Uint<64>;
export ledger owner: Bytes<32>;
export ledger totalSupply: Counter;

Every field you declare with export ledger is stored on every network node in plaintext. Your dApp can read it. So can every other dApp, every indexer, every curious person running a node. There's no visibility modifier that makes it "semi-public" or "only readable by the contract." It's public.

Most developers understand this in the abstract. Where it breaks down in practice is with per-user data. The classic mistake: storing individual user balances in export ledger. That's a privacy violation, not a compiler error, not a proof failure, just a design error that quietly exposes data you probably meant to protect.

The heuristic: If removing a ledger field would break another user's ability to interact with the contract, it belongs on-chain. If only one user cares about the value, it almost certainly shouldn't be.

Where private data actually lives

Private data comes in through witnesses, callback functions declared in Compact, implemented in your TypeScript dApp, and executed locally on the user's device:

witness getBalance(): Uint<64>;
witness secretKey(): Bytes<32>;
witness userNonce(): Field;

When a circuit calls a witness, the value it returns never touches the chain. Not even as an encrypted blob. The chain sees a ZK proof that the circuit ran correctly given some private inputs. The inputs themselves stay local.

This is what makes Compact's privacy model different from Solidity's private keyword. In Solidity, private is a visibility modifier, the data is still on-chain, just not directly accessible from other contracts. In Compact, witness data is structurally off-chain. It can't go on-chain, because there's no mechanism to put it there. The proof proves the computation; the input stays local.

disclose() is not what you think it is

At some point you'll need to move something from private to public, store a commitment, record a result, update global state. That's what disclose() is for.

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

Here's what disclose() is not:

• It's not encryption. The value is not transformed.
• It's not a runtime operation. There's no cost.
• It's not a permission check. It doesn't verify you're allowed to do this.

It's a compile-time annotation. You're telling the compiler: "I know this value is private, and I am intentionally making it public." The compiler records the declaration and permits the data flow. Without it, witness data trying to reach the ledger is a compile error.

The implication: everything after disclose() is public. The value you disclose will be visible on-chain as plaintext. Disclose it only if that's what you actually want.

The compiler tracks the boundary, everywhere.

What makes this model powerful is that the compiler doesn't just check assignment statements. It tracks witness data through every operation: arithmetic, type conversions, struct construction, helper circuits.

circuit obfuscate(x: Field): Field {
  return x + 73;
}

export circuit record(): [] {
  const s = getBalance() as Field;
  const x = obfuscate(s);
  balance = x as Bytes<32>;  // compiler error
}

Passing witness data through x + 73 doesn't make it non-private. The compiler knows the output depends on the private input, so it's still tainted. You need disclose() at the boundary, not buried in the middle of the computation.

This also means comparison results count:

// compiler error: result reveals information about witness data
export circuit balanceExceeds(n: Uint<64>): Boolean {
  return getBalance() > n;
}

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

Even a boolean that's derived from private data is a disclosure. The compiler catches it.

When you need to prove something about private data without revealing it

This is where the commitment pattern comes in. It solves a specific problem: you need to demonstrate that a private value exists and hasn't changed, without putting the value on-chain.

export ledger balanceCommitments: Map<Bytes<32>, Bytes<32>>;

export circuit commitBalance(value: Uint<64>): [] {
  const nonce = freshNonce();
  const commitment = persistentCommit<Uint<64>>(value, nonce);
  balanceCommitments.insert(
    disclose(callerAddress()),
    disclose(commitment)
  );
}

What goes on-chain: the commitment (a hash with a random nonce). What stays local: the actual balance. A later circuit can prove the balance meets some condition — exceeds a threshold, is non-negative, without revealing the number. The commitment on-chain proves the private value was committed to and hasn't changed.

The nonce is critical. Two commitments with the same nonce and same value are identical on-chain — anyone watching can correlate them. Always use a fresh nonce.

The design shift this requires

Once this model clicks, you stop designing contracts around functions and start designing them around data residency.

Before: "What should this circuit do?"

After: "Where does this data live? What needs to be provable publicly? What must never leave the user's device?"

These questions affect everything downstream: what goes in export ledger, what stays in witnesses, where commitments make sense, which circuits need disclose() and which don't. Get the data residency wrong at the design stage and you'll either have a privacy leak or a system that can't verify what it needs to verify.

Most bugs in Compact contracts aren't logic errors. They're boundary errors, data ending up in the wrong world, or a contract that can't prove what it needs to because the private data that would make the proof possible was never accessible in the right form.

The one question to ask before writing any ledger field

If this value were visible to every person on the internet, would that be a problem?

If yes: it belongs in witnesses, not in export ledger. Use the commitment pattern if you need public provability without public visibility.

If no: export ledger is the right place.

Ledger State and Explicit Disclosure chapters cover this in full

The Compact Book walks through the commitment pattern with working examples, the full disclose() rules including the standard library exceptions (transientCommit is a special case), and how the compiler error traces tell you exactly where a boundary violation occurred.

→ Compact Book

Post #4 covers witnesses in depth, specifically why witness results are untrusted inputs, and what "the proof proves correct logic, not sensible inputs" means for how you write validation. That one has teeth.