Forem: Ameer Abdulaleem

Selective Disclosure Patterns in Compact: A Developer's Guide

Ameer Abdulaleem — Mon, 27 Apr 2026 12:14:42 +0000

INTRODUCTION

Blockchain transparency is a double edged sword. Every transaction, every state change, and every interaction sits on a public ledger for anyone to inspect. For many applications this is a feature. For applications handling sensitive data it is a dealbreaker.

Midnight solves this with a dual state architecture. Your DApp maintains both public state visible on chain and private state stored locally with users. The bridge between these two worlds is selective disclosure: the ability to prove something is true about your private data without revealing the data itself.

This tutorial covers the patterns that make selective disclosure work in Compact. You will learn how to use disclose() correctly, understand what information is safe to expose, implement domain separated hashing to prevent user tracking across different properties, and apply a systematic privacy audit to your own contracts.

Prerequisites

Before you continue, make sure you have:

The Compact toolchain installed (follow the installation guide)
A basic understanding of Compact syntax (review the Hello World tutorial)
The Midnight MCP tool available for validating your code

What Is Selective Disclosure?

In traditional smart contract development every input to a function becomes public the moment a transaction is submitted. There is no privacy. The contract sees everything and so does everyone else.

Compact changes this. Circuit parameters are private by default. Consider this simple function signature:

export circuit storeMessage(newMessage: Opaque<"string">): [] {
    // newMessage is private here
}

The Opaque<"string"> type tells the compiler that newMessage is a private input. It exists in the user's local execution environment but never appears on chain in its raw form.

Selective disclosure happens when you decide to move data from the private context to the public ledger. You do this with the disclose() function:

export circuit storeMessage(newMessage: Opaque<"string">): [] {
    message = disclose(newMessage);
}

This single line makes a deliberate choice. The message content becomes public state stored in the message ledger variable. Everyone can now read it.

But selective disclosure is about more than just toggling visibility. It is about revealing proofs instead of raw data. You can disclose that a condition is met without disclosing the condition itself. You can disclose a hash commitment now and reveal the preimage later. You can disclose aggregated results while keeping individual inputs hidden.

`disclose()` Usage Patterns

The disclose() function is the only mechanism for moving data from private context to public state. Understanding its patterns is fundamental to building privacy preserving DApps.

Pattern 1: Direct Disclosure

The simplest pattern. You have private data and you want it on chain.

pragma language_version 0.22;

export ledger publicCounter: Counter;

export circuit increment(amount: Opaque<Uint<32>>): [] {
    let increment_by = disclose(amount);
    publicCounter.increment(increment_by);
}

Here the user provides a private amount. The circuit discloses it and increments the public counter. The amount becomes visible to everyone. Use this pattern only when the data is intentionally non sensitive.

Pattern 2: Conditional Disclosure with Assertions

Often you want to disclose something only after verifying it meets certain conditions.

pragma language_version 0.22;

export ledger allowedAmount: Uint<32>;

export circuit submitAmount(amount: Opaque<Uint<32>>): [] {
    let value = disclose(amount);
    assert(value <= allowedAmount, "Amount exceeds allowed limit");
    // Proceed with business logic using the disclosed value
}

The assertion runs in the ZK circuit. If it fails the entire transaction reverts. The amount is disclosed but only after proving it satisfies the constraint.

Pattern 3: Disclosing Derived Values

This is where selective disclosure becomes powerful. Instead of disclosing raw inputs you disclose a computed result that reveals only what is necessary.

pragma language_version 0.22;
import CompactStandardLibrary;

export ledger userEligibility: Map<Bytes<32>, bool>;

export circuit proveEligibility(
    birthYear: Opaque<Uint<16>>,
    currentYear: Uint<16>
): [] {
    let age = currentYear as Uint<32> - (birthYear as Uint<32>);
    let isAdult = age >= 18;

    const _sk = localSk();
    let pubKey = getDappPublicKey(_sk);

    userEligibility.insert(disclose(pubKey), disclose(isAdult));
}

The user provides their birth year as a private input. The circuit computes their age and determines adulthood status. Only the boolean result isAdult is disclosed. The actual birth year never leaves the private context.

Pattern 4: Commit Now, Reveal Later

This two phase pattern is essential for auctions, voting, and any scenario requiring a commitment period.

pragma language_version 0.22;
import CompactStandardLibrary;

export ledger commitment: Bytes<32>;
export ledger revealedValue: Uint<32>;

export circuit commit(value: Opaque<Uint<32>>, salt: Opaque<Bytes<32>>): [] {
    let hash = persistentHash<Vector<2, Bytes<32>>>([
        value as Bytes<32>,
        salt
    ]);
    commitment = disclose(hash);
}

export circuit reveal(value: Opaque<Uint<32>>, salt: Opaque<Bytes<32>>): [] {
    let computedHash = persistentHash<Vector<2, Bytes<32>>>([
        value as Bytes<32>,
        salt
    ]);
    assert(computedHash == commitment, "Commitment mismatch");

    revealedValue = disclose(value);
}

In the commit phase the user submits a hash of their value and a salt. In the reveal phase they provide both original inputs. The circuit verifies the hash matches before disclosing the value. This prevents front running and ensures users cannot change their submission after seeing others.

What Is Safe to Disclose vs What Leaks Privacy

The line between safe and unsafe disclosure is not always obvious. Here is a framework for evaluating your disclosure decisions.

Safe to Disclose

Aggregates and counts. The total number of participants in an event reveals nothing about individual identities.

Boolean results of private checks. Knowing that someone is over 18 does not reveal their exact age.

Public keys derived with DApp specific hashing. See the domain separation section below for why this matters.

Hashes and commitments. A hash without its preimage reveals nothing about the underlying data assuming sufficient entropy.

Enumerated states. Disclosing that an auction is OPEN or CLOSED is necessary for coordination.

Unsafe to Disclose

Direct personal identifiers. Names, email addresses, government ID numbers. Never put these on chain even in encrypted form without careful consideration.

Linkable pseudonyms. If you disclose the same public key across multiple interactions within the same DApp you create a linkage profile. Always use DApp specific key derivation.

Precise numeric values when only a range is needed. Disclosing an exact salary of 84750 when you only need to prove it exceeds 50000 leaks unnecessary information.

Correlatable timestamps. The exact block height of a user's interaction combined with other disclosed data can create timing correlation attacks.

Raw private keys or seeds. This should be obvious but it bears repeating. Never write disclose(localSk()) in your contract.

The Linkability Problem

Consider this vulnerable pattern:

// DO NOT USE - Vulnerable to cross interaction tracking
export circuit registerUser(): [] {
    const _sk = localSk();
    let pubKey = publicKey(_sk);  // Standard public key derivation
    registeredUsers.insert(disclose(pubKey));
}

export circuit submitVote(): [] {
    const _sk = localSk();
    let pubKey = publicKey(_sk);
    // Same pubKey used across circuits
}

If the same public key appears in multiple contracts or even multiple circuits within the same contract, an observer can link all of that user's activity together. This defeats the privacy guarantees you are trying to provide.

Domain Separated Hashing for Cross Property Unlinkability

Domain separation is the technique of generating different identifiers for the same user across different contexts. It ensures that an observer cannot link a user's activity in one part of your DApp to their activity in another.

The Pattern

The Midnight example contracts demonstrate this pattern consistently. Here is the implementation from the Private Guest List contract:

export circuit getDappPublicKey(_sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>([
        pad(32, "guest-list:pk:"),
        _sk
    ]);
}

The user's private key is hashed with a domain specific string. The resulting public key is unique to this DApp. Even if the same user interacts with another DApp their identifier will be completely different because the domain string differs.

Multiple Domains Within a Single DApp

You can extend this pattern to create separate unlinkable identities for different features within the same DApp:

pragma language_version 0.22;
import CompactStandardLibrary;

export circuit getVoterPublicKey(_sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>([
        pad(32, "election:voter:"),
        _sk
    ]);
}

export circuit getCandidatePublicKey(_sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>([
        pad(32, "election:candidate:"),
        _sk
    ]);
}

A user who is both a voter and a candidate in the same election DApp will have two different unlinkable public keys. Their voting activity cannot be correlated with their candidate registration.

The Battleship Example

The Battleship contract uses domain separation to prevent cross game tracking:

circuit getDappPubKey(_sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>([
        pad(32, "battleship:pk:"),
        _sk
    ]);
}

Each game instance could further extend this by incorporating a game ID:

circuit getGameSpecificPubKey(_sk: Bytes<32>, gameId: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<3, Bytes<32>>>([
        pad(32, "battleship:game:"),
        gameId,
        _sk
    ]);
}

Now the same player has a different unlinkable identity in every game they play.

Privacy Audit Checklist for Developers

Before deploying a Compact contract conduct this systematic privacy audit. Each question forces you to examine a specific aspect of your disclosure patterns.

1. Disclosure Inventory

List every occurrence of disclose() in your contract. For each one answer:

What specific data is being disclosed?
Why must this data be public?
Could a proof of a property replace the raw data?

If you cannot justify why something must be public reconsider whether it belongs on chain at all.

2. Linkability Analysis

For each disclosed identifier ask:

Does this identifier appear in multiple circuits within the same contract?
Does this identifier appear in other contracts deployed by this DApp?
Could an observer correlate this identifier with activity in other DApps?

If any answer is yes implement domain separation using persistentHash with a unique domain string.

3. Timing Attack Surface

Examine your contract for timing sensitive disclosures:

Are there state transitions that reveal when specific users act?
Do you disclose counts or sizes that change in predictable ways based on user behavior?
Could block height combined with other disclosures create a timing fingerprint?

Consider adding random delays or batching operations where appropriate.

4. Commitment Scheme Validation

If your contract uses commit reveal patterns verify:

Is a salt or nonce included in the commitment hash?
Does the salt have sufficient entropy? Hardcoded or predictable salts offer no protection.
Is the reveal phase protected against replay attacks?
What prevents a user from refusing to reveal after the commitment period?

5. Aggregation Check

When disclosing aggregate data verify:

Is the aggregate sufficiently large to provide k anonymity? A group of two is not private.
Could an attacker manipulate inputs to isolate a specific user's contribution?
Are you disclosing the aggregate before all contributions are finalized?

6. Cross Circuit Information Flow

Consider what an observer learns by comparing the public outputs of different circuits:

Does circuit A disclose something that circuit B later proves about the same user?
Could timing analysis across circuits create a linkage?
Do different circuits use the same derived public key?

7. Emergency Stop Consideration

Ask yourself:

If a privacy vulnerability is discovered can the contract be paused?
Do users have a way to withdraw or nullify their private data if needed?
Is there a mechanism for users to rotate their identifiers?

8. Documentation Completeness

Finally verify that your contract includes:

Comments explaining what each disclosed value represents
Documentation of the privacy guarantees and limitations
Clear warnings about what information becomes public and when

A Complete Example: Private Age Verification

Let us put these patterns together into a complete contract that demonstrates selective disclosure principles correctly.

pragma language_version 0.22;
import CompactStandardLibrary;

export ledger verifiedAdults: Set<Bytes<32>>;
export ledger verificationCount: Counter;

witness localSk(): Bytes<32>;

constructor() {
    // No constructor initialization needed
}

export circuit verifyAge(
    birthYear: Opaque<Uint<16>>,
    currentYear: Uint<16>
): [] {
    // Compute age without disclosing birth year
    let age = currentYear as Uint<32> - (birthYear as Uint<32>);
    let isAdult = age >= 18;

    // Only disclose the boolean result
    assert(disclose(isAdult), "You must be 18 or older");

    // Generate DApp specific public key for unlinkability
    const _sk = localSk();
    let dappPubKey = getDappPublicKey(_sk);

    // Record verification without linking to other DApps
    verifiedAdults.insert(disclose(dappPubKey));
    verificationCount.increment(1);
}

export circuit getDappPublicKey(_sk: Bytes<32>): Bytes<32> {
    return persistentHash<Vector<2, Bytes<32>>>([
        pad(32, "age-verification:pk:"),
        _sk
    ]);
}

This contract demonstrates several best practices:

The user's birth year is private and never disclosed
Only the boolean adulthood status is disclosed through the assertion
The user is recorded using a DApp specific public key preventing cross DApp tracking
The verification count is public allowing transparency about total verifications without revealing who was verified

Next Steps

Follow-up the clear further explanation README of my commit and gets your code compiled easily: https://github.com/Ameerabdulaleem/midnight_network_selective_disclosure_patterns.git

Selective disclosure is a skill that improves with practice. Here are concrete ways to deepen your understanding:

Study the official examples. The Private Guest List, Election, and Private Reserve Auction contracts all demonstrate sophisticated disclosure patterns.
Use the Midnight MCP tool. Before submitting any work, run your Compact code through midnight-mcp to validate compilation and catch common mistakes.
Join the community. The Midnight Discord and Developer Forum are active with developers working through the same privacy challenges you are.
Apply the audit checklist to your own contracts. The best way to internalize these patterns is to critically examine your own code.

Selective disclosure is what makes Midnight uniquely suited for real world applications that require both decentralization and data protection. Master these patterns and you will build DApps that are not just functional but genuinely private.

Rust Ownership Explained for Solidity Developers: The Mindset Shift That Changes Everything in Web3

Ameer Abdulaleem — Mon, 30 Mar 2026 14:37:34 +0000

If you have been writing smart contracts in Solidity and now want to learn Rust for Solana, Polkadot, or NEAR, you will feel a big change. The syntax is different, but the real challenge is how you think about memory.

In Solidity the Ethereum Virtual Machine handles memory for you. Rust asks you to manage memory yourself with a simple but powerful system called Ownership.

This one concept is the biggest mindset shift. Once you understand it, the rest of Rust feels natural and safe. Let me explain it step by step in plain English.

The 3 Key Things About Rust Ownership

Ownership Rules

Every piece of data has exactly one owner. When that owner goes out of scope, Rust automatically drops the data and frees the memory. No garbage collector needed. This keeps your program fast and predictable.
Borrowing

You do not always need to move ownership. You can borrow the data instead.
- &T is an immutable borrow – many people can read it at the same time.
- &mut T is a mutable borrow – only one person can change it at a time. The compiler checks these rules before your code runs.
Lifetimes

Rust tracks how long a reference stays valid. It does this at compile time so you never use data that has already been dropped. This stops dangerous bugs like “use after free”.

Simple Code Examples You Can Try Right Now

Example 1: Ownership Move

fn main() {
    let s1 = String::from("Solana is fast");
    let s2 = s1;                    // ownership moves to s2
    // println!("{}", s1);          // This line will not compile
    println!("{}", s2);             // Only s2 can use the data now
}

Example 2: Borrowing in Action

Rustfn main() {
    let mut book = String::from("Rust for Web3");

    let reader1 = &book;            // anyone can read
    let reader2 = &book;            // multiple readers are fine

    let writer = &mut book;         // only one writer allowed
    writer.push_str(" developers");

    println!("{}", book);
}

Example 3: Lifetimes (easy version)

Rustfn longest<'a>(first: &'a str, second: &'a str) -> &'a str {
    if first.len() > second.len() {
        first
    } else {
        second
    }
}

Think of Memory Like a Library Book

Imagine every piece of data is a book in a library.

Ownership = only one library card per book. When you finish with the book, it goes back on the shelf automatically.
Borrowing = you can read the book (&T) or write notes in it (&mut T). Many people can read at once, but only one person can write.
Lifetimes = the due date on the card. The librarian (Rust compiler) checks the date before you leave so the book never disappears while someone is still using it.

This system feels strict at first, but it protects you. You get memory safety without slowing down your code – perfect for high-speed blockchains.

Why This Matters for Real Web3 Projects
In blockchain, one small memory bug can lose millions of dollars. Rust’s ownership rules catch those bugs before your contract even runs. That is why Solana, Polkadot, and NEAR chose Rust. Companies building serious infrastructure want developers who understand this safety mindset.
How to Practice Ownership Today

Write a small Rust program that moves ownership and see the compiler error.
Change it to use borrowing and watch the error disappear.
Try the longest function above with strings of different lengths.

Do this for 15 minutes and you will feel the shift.

Final Thoughts
Learning Rust ownership is like learning to drive a manual car after years of automatic. It feels harder at first, but once you get it, you have much more control and confidence.

This is only the second article in my Rust for Web3 series.

Next we will cover Traits and how they let you build reusable DeFi components.

If this helped you understand the mindset shift, drop a comment below. Tell me what part was confusing before and clear now. I read every comment and I love helping new Web3 developers.

The Three Reasons RUST is Winning Web3 in 2026: Safety, Performance, and Fearless Concurrency

Ameer Abdulaleem — Sun, 29 Mar 2026 20:02:22 +0000

If you've been following blockchain development lately, you've probably noticed a clear trend: major projects like Solana, Polkadot, and NEAR are all built using Rust.

This is not just hype. Rust solves fundamental challenges when building secure, high-performance decentralized systems where a single bug can cost millions.

At its core, Rust brings two revolutionary features that make it perfect for blockchain infrastructure.

First, Rust delivers guaranteed memory safety without a garbage collector. This means the compiler catches dangerous bugs like null pointer dereferencing and data races at compile time, before your code ever runs. In blockchain, where security is non-negotiable, this protection is essential.

Second, Rust offers zero-cost abstractions. You can write clean, high-level code that feels modern and readable, yet it compiles down to performance that rivals hand-written C or C++. For blockchains that need to handle thousands of transactions per second, this combination of readability and raw speed is a game-changer.

The Three Core Advantages of Rust

Here are the three pillars that make Rust stand out for Web3:

Memory Safety Guarantees

Rust's ownership system and borrow checker ensure that common catastrophic bugs (null pointers, data races) are impossible at runtime. The compiler acts like a strict security auditor, stopping these issues before deployment. This is why teams building critical infrastructure trust Rust.
Zero-Cost Abstractions

You get high-level features like iterators and pattern matching without any performance penalty. The code you write reads beautifully but runs as efficiently as low-level C. This lets developers focus on logic instead of micro-optimizations while still hitting the speed blockchains demand.
Fearless Concurrency

Writing safe parallel code is notoriously error-prone in most languages. Rust's type system enforces thread safety at compile time, so you can confidently use modern multi-core processors for validators, indexers, and high-throughput nodes without subtle bugs that are hard to debug.

Think of It Like Building a Championship Race Car

Building a blockchain is like engineering a high-stakes race car. You need blazing speed (performance) but zero tolerance for mechanical failure (security).

Other languages often force a trade-off: build something fast that might crash, or something safe that is too slow.

Rust lets you have both. Its memory safety provides an unbreakable chassis, zero-cost abstractions deliver advanced aerodynamics for top speed, and fearless concurrency ensures perfect engine synchronization. You get maximum performance without compromising reliability.

This is exactly why Solana, Polkadot, NEAR, and many other high-performance chains chose Rust for their core infrastructure.

Getting Started with Rust for Web3

If you're coming from JavaScript, Python, or Solidity, the biggest mindset shift is embracing ownership and borrowing. Once that clicks, the rest (Cargo, traits, error handling with Result and Option) builds on a solid, safe foundation.

Rust is not just another language trend. It is an architectural upgrade for building the next generation of scalable, secure blockchains.

What has been your experience learning Rust for Web3? Are you building on Solana, Polkadot, NEAR, or another ecosystem? Share your thoughts or questions in the comments.

Tags: rust, web3, blockchain, solana, polkadot, programming, rustlang, systemsprogramming

Cover Image Suggestion: Use one of your existing carousels or race car analogy visuals (dark theme works great on Dev.to). If you need a new one generated, let me know.

Series Note: This is the first article in a series on Rust for Web3 developers.
Next up: Deep dive into Rust Ownership explained like a library.