DEV Community: Ameer Abdulaleem

Contract-State Accounting vs UTXO Tokens: Two Models for On-Chain Value

Ameer Abdulaleem — Sun, 03 May 2026 09:49:13 +0000

## INTRODUCTION

Every blockchain application that handles value needs to answer the same question: how do you track who owns what? There are two dominant approaches, and choosing between them shapes your entire contract architecture.

Contract-state accounting behaves like a bank ledger. A single smart contract holds a balance map, and transactions update entries in place. The UTXO model behaves like physical cash. Each unit of value exists as an independent object that gets consumed and recreated with every transfer.

Midnight supports both patterns, and each has different tradeoffs for privacy, complexity, and scalability. This tutorial explains both models, shows you how to implement them in Compact, and helps you decide which one fits your use case.

Prerequisites

Before you continue, make sure you have:

The Compact toolchain installed by following the installation guide
A working understanding of Compact syntax from the Hello World tutorial
Familiarity with the disclose() function and selective disclosure concepts

What Is Contract-State Accounting?

Contract-state accounting uses a central registry. The smart contract maintains a single data structure, typically a Map, that tracks every account balance. When Alice sends 50 tokens to Bob, the contract decreases Alice's balance by 50 and increases Bob's balance by 50. The total supply is implicit in the sum of all balances.

This model mirrors how a bank operates. The bank keeps a ledger, and every transaction is a double entry update to that ledger.

Here is a basic implementation in Compact:

pragma language_version 0.22;
import CompactStandardLibrary;

export ledger balances: Map<Bytes<32>, Uint<64>>;
export ledger totalSupply: Uint<64>;

witness localSk(): Bytes<32>;

constructor(initialSupply: Uint<64>) {
    const _sk = localSk();
    let creator = getDappPublicKey(_sk);
    balances.insert(disclose(creator), disclose(initialSupply));
    totalSupply = disclose(initialSupply);
}

export circuit transfer(
    recipient: Bytes<32>,
    amount: Uint<64>
): [] {
    const _sk = localSk();
    let sender = getDappPublicKey(_sk);

    let senderBalance = balances.lookup(sender);
    assert(senderBalance >= amount, "Insufficient balance");

    let newSenderBalance = senderBalance - amount;
    balances.insert(sender, newSenderBalance);

    let recipientBalance = balances.lookup(recipient);
    let newRecipientBalance = recipientBalance + amount;
    balances.insert(recipient, newRecipientBalance);
}

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

This implementation is straightforward. Every transfer reads two balances, performs arithmetic, and writes two updated balances. The state changes are destructive. Once Alice's balance is updated, the previous balance is gone forever.

Advantages of Contract-State Accounting

Simplicity: The mental model is intuitive. Developers coming from traditional backend systems immediately understand a balance map.

Gas predictability: Each transfer performs a constant number of operations regardless of transaction history. Two map lookups, two map insertions, and some arithmetic.

Easy aggregation: If you need to know the total supply or the number of holders, the data is right there in the contract state. You can query it directly.

Familiar tooling: The pattern works well with standard wallet interfaces. Users see a balance and a send button.

Disadvantages of Contract-State Accounting

Privacy challenges: In a fully public implementation, every balance is visible to every observer. Midnight mitigates this with ZK proofs, but the pattern still requires careful selective disclosure design to protect individual balances.

State bloat: The balance map grows with every new holder and never shrinks. Even accounts with zero balance may need to remain to preserve historical data.

Concurrency issues: If two transactions try to update the same balance simultaneously, one will fail. This creates friction in high throughput applications.

What Is the UTXO Model?

UTXO stands for Unspent Transaction Output. The mental model is physical cash. When you hold a ten dollar bill, that bill is a discrete object with its own serial number and value. When you pay for something that costs seven dollars using that ten dollar bill, two things happen: the ten dollar bill is destroyed, a seven dollar bill goes to the merchant, and a three dollar bill comes back to you as change.

In a UTXO system, every unit of value is a distinct object stored on chain. Each object has an owner and an amount. A transaction consumes input UTXOs and creates output UTXOs. The sum of input amounts must equal the sum of output amounts, preserving the total supply.

Here is a Compact implementation of a basic UTXO token:

pragma language_version 0.22;
import CompactStandardLibrary;

export ledger utxos: Map<Bytes<32>, Uint<64>>;
export ledger utxoOwners: Map<Bytes<32>, Bytes<32>>;

witness localSk(): Bytes<32>;

constructor(initialSupply: Uint<64>) {
    const _sk = localSk();
    let creator = getDappPublicKey(_sk);

    let utxoId = persistentHash<Vector<2, Bytes<32>>>([
        pad(32, "utxo:genesis:"),
        _sk
    ]);

    utxos.insert(disclose(utxoId), disclose(initialSupply));
    utxoOwners.insert(disclose(utxoId), disclose(creator));
}

export circuit transfer(
    inputUtxoId: Opaque<Bytes<32>>,
    outputAmount1: Uint<64>,
    outputAmount2: Uint<64>,
    recipient1: Bytes<32>,
    recipient2: Bytes<32>
): [] {
    // Verify ownership of the input UTXO
    const _sk = localSk();
    let sender = getDappPublicKey(_sk);

    let utxoId = disclose(inputUtxoId);
    assert(utxos.member(utxoId), "UTXO does not exist");
    assert(utxoOwners.lookup(utxoId) == sender, "You do not own this UTXO");

    let inputAmount = utxos.lookup(utxoId);

    // Verify amount conservation
    assert(
        inputAmount == outputAmount1 + outputAmount2,
        "Input and output amounts must match"
    );

    // Destroy the input UTXO
    utxos.remove(utxoId);
    utxoOwners.remove(utxoId);

    // Create output UTXOs
    if (outputAmount1 > 0) {
        let newUtxoId1 = persistentHash<Vector<3, Bytes<32>>>([
            pad(32, "utxo:output:"),
            utxoId,
            pad(32, "1")
        ]);
        utxos.insert(disclose(newUtxoId1), outputAmount1);
        utxoOwners.insert(disclose(newUtxoId1), recipient1);
    }

    if (outputAmount2 > 0) {
        let newUtxoId2 = persistentHash<Vector<3, Bytes<32>>>([
            pad(32, "utxo:output:"),
            utxoId,
            pad(32, "2")
        ]);
        utxos.insert(disclose(newUtxoId2), outputAmount2);
        utxoOwners.insert(disclose(newUtxoId2), recipient2);
    }
}

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

This implementation captures the essence of the UTXO model. Each UTXO is a distinct entry in the utxos map with a corresponding owner. A transfer destroys one UTXO and creates up to two new ones, typically one for the recipient and one for change back to the sender.

Advantages of the UTXO Model

Natural privacy; Because UTXOs are independent objects, you can use different keys for each one. An observer cannot trivially link multiple UTXOs to the same owner without additional information.

Parallelism; Transactions that consume different UTXOs do not conflict with each other. Alice sending to Bob and Charlie sending to Dave can process simultaneously because they touch different state entries.

Auditability; The total supply is preserved by construction. Every transaction must balance, so you can verify the entire history without trusting a central authority.

Resistance to replay; Each UTXO has a unique identifier. Once consumed, a UTXO cannot be used again because it no longer exists in the state.

Disadvantages of the UTXO Model

Complexity; The model is less intuitive for developers used to account-based systems. Generating change outputs, selecting which UTXOs to consume, and managing fragmented balances adds surface area for bugs.

Fragmentation; Over time, a user may accumulate many small UTXOs. Spending a large amount requires combining multiple inputs, which increases transaction size and complexity.

State growth; Every transaction creates new UTXOs. Even as old ones are consumed, the total number of UTXOs in existence tends to grow, especially if users do not consolidate their holdings.

Comparing the Two Models

Let us examine the same scenario implemented in both models to highlight the practical differences.

Scenario: Alice sends 30 tokens to Bob

Contract-state accounting:

The contract reads Alice's balance. If she has at least 30 tokens, it subtracts 30 from her balance and adds 30 to Bob's balance. Two state entries are updated. The transaction is a single unit of work.

UTXO model:

Alice's wallet selects one or more UTXOs that sum to at least 30 tokens. Suppose she has a single UTXO worth 50 tokens. The transaction consumes that UTXO and creates two new ones: 30 tokens owned by Bob and 20 tokens owned by Alice as change. One state entry is destroyed, two are created.

The UTXO approach creates more on-chain objects, but each object reveals less about the overall distribution of funds. An observer sees a 50 token UTXO disappear and a 30 and 20 appear, but they cannot trivially tell which is the payment and which is the change without additional analysis.

When to Choose Contract-State Accounting

Choose this model when:

Your application needs frequent balance queries from the contract itself
You are building something familiar like a token with standard wallet integrations
The user experience of seeing a single balance matters more than transaction level privacy
Your total number of holders is reasonably bounded

When to Choose the UTXO Model

Choose this model when:

Privacy is a primary design goal and you want to avoid balance correlation
Your application benefits from parallel transaction processing
You need strong guarantees about supply preservation that are enforced by the transaction structure itself
You are building payment systems or exchange mechanisms

Hybrid Approaches

You are not forced to pick one model exclusively. Many applications combine elements of both patterns.

For example, a DApp might store user balances as a map for quick lookups while also issuing UTXO style receipts for individual transactions. The balance map provides convenience, and the receipts provide auditability.

Here is a sketch of how that might look:

pragma language_version 0.22;
import CompactStandardLibrary;

export ledger balanceMap: Map<Bytes<32>, Uint<64>>;
export ledger transactionReceipts: Map<Bytes<32>, Bytes<32>>;

witness localSk(): Bytes<32>;

export circuit deposit(amount: Opaque<Uint<64>>): [] {
    const _sk = localSk();
    let user = getDappPublicKey(_sk);

    let currentBalance = balanceMap.lookup(user);
    let newBalance = currentBalance + disclose(amount);
    balanceMap.insert(user, newBalance);

    let receiptId = persistentHash<Vector<2, Bytes<32>>>([
        pad(32, "receipt:"),
        _sk
    ]);
    let receiptData = pad(64, "deposit");
    transactionReceipts.insert(disclose(receiptId), receiptData);
}

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

The balance map handles the operational needs of the application. The receipt map provides an immutable audit trail. Each solves a different problem, and together they offer more than either alone.

Practical Recommendations

Based on these models, here is a decision framework for your own contracts:

Start with contract-state accounting if you are building a straightforward token or a DApp where user experience and developer simplicity are priorities. The pattern is easier to get right and easier to debug.
Move to the UTXO model if you discover privacy or concurrency requirements that the account model cannot satisfy. The additional complexity is worth it when these properties matter.
Consider a hybrid approach if you need both operational efficiency and an audit trail. Just be clear about which state serves which purpose.
Regardless of which model you choose, apply domain separated hashing for all user identifiers. This prevents cross DApp tracking and preserves the privacy guarantees you are building into your contract logic.
Test your assumptions on a local Devnet before deploying to a public testnet. Both models behave differently under load, and early testing catches architecture problems before they become expensive.

A Privacy Note on Both Models

Neither model automatically guarantees privacy. In contract-state accounting, if you disclose user public keys directly in the balance map, every balance becomes linkable to every transaction that user makes. In the UTXO model, if you reuse the same owner key across multiple UTXOs, you create the same linkability problem.

Always derive DApp specific public keys using domain separation. Consider whether you can use commitments instead of raw values. And apply the selective disclosure audit checklist covered in the companion tutorial on disclosure patterns.

Next Steps

Understanding these two models gives you a foundation for designing value transfer systems on Midnight. To deepen your knowledge:

Study the Token Transfers example in the Midnight documentation to see a production oriented implementation.
Experiment with both patterns using the create-mn-app scaffolding tool. Build the same simple token with each model and compare the developer experience.
Join the Midnight Discord and share your implementation. The community is actively discussing these design patterns.
Apply the selective disclosure audit checklist from the companion tutorial to whichever model you choose. Privacy is not automatic, it requires deliberate design.

Contract-state accounting and the UTXO model are both valid paths. The right choice depends on your application requirements and your users needs. Now you have the tools to make that choice confidently.

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.

DEV Community: Ameer Abdulaleem

Contract-State Accounting vs UTXO Tokens: Two Models for On-Chain Value

Prerequisites

What Is Contract-State Accounting?

Advantages of Contract-State Accounting

Disadvantages of Contract-State Accounting

What Is the UTXO Model?

Advantages of the UTXO Model

Disadvantages of the UTXO Model

Comparing the Two Models

Scenario: Alice sends 30 tokens to Bob

When to Choose Contract-State Accounting

When to Choose the UTXO Model

Hybrid Approaches

Practical Recommendations

A Privacy Note on Both Models

Next Steps

Selective Disclosure Patterns in Compact: A Developer's Guide

INTRODUCTION

Prerequisites

What Is Selective Disclosure?

disclose() Usage Patterns

Pattern 1: Direct Disclosure

Pattern 2: Conditional Disclosure with Assertions

Pattern 3: Disclosing Derived Values

Pattern 4: Commit Now, Reveal Later

What Is Safe to Disclose vs What Leaks Privacy

Safe to Disclose

Unsafe to Disclose

The Linkability Problem

Domain Separated Hashing for Cross Property Unlinkability

The Pattern

Multiple Domains Within a Single DApp

The Battleship Example

Privacy Audit Checklist for Developers

1. Disclosure Inventory

2. Linkability Analysis

3. Timing Attack Surface

4. Commitment Scheme Validation

5. Aggregation Check

6. Cross Circuit Information Flow

7. Emergency Stop Consideration

8. Documentation Completeness

A Complete Example: Private Age Verification

Next Steps

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

The 3 Key Things About Rust Ownership

Simple Code Examples You Can Try Right Now

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

The Three Core Advantages of Rust

Think of It Like Building a Championship Race Car

Getting Started with Rust for Web3

`disclose()` Usage Patterns