Why this matters​

Midnight is approaching mainnet. The ecosystem already has hundreds of active developers building with Compact, deploying on Preprod, and shipping real applications. But activity that isn't attributed doesn't get counted, and that invisibility has real consequences for the ecosystem you're helping to build.

Establishing a clear public record of development activity ensures that the broader blockchain industry recognizes the growth of Midnight Network. Accurate attribution is a functional necessity for the ecosystem and establishes a standardized framework for documenting technical contributions.

The attribution process​

Electric Capital produces the most widely cited developer report in blockchain. Investors, protocols, and media use it to understand which ecosystems are growing, which are stagnant, and where to pay attention. Their methodology is public: they track GitHub commits, contributor counts, and repository metadata across every major blockchain ecosystem. If your repo doesn't have the right metadata, their tooling won't associate it with Midnight, regardless of how active or high-quality the work is.

Midnight is submitting its ecosystem map to Electric Capital for the first time, ahead of mainnet. This is a one-time window to establish a credible public record of where the ecosystem stands from day one. Developer counts from the weeks surrounding a mainnet launch are captured in a rolling window that informs how new ecosystems are ranked and covered. Ecosystems that show up in that window with strong numbers get recognized. Ecosystems that don't, start from a deficit they spend months correcting.

Compounding developer results​

The changes below take under five minutes per repository. They are small, permanent, and consequential. Beyond writing code, implementing these metadata standards is a high-imact action for ecosystem growth. Every repo that completes them is a developer who gets credited for building on Midnight.

Step 1: Add GitHub topics​

GitHub topics are how Electric Capital (and other ecosystem trackers) programmatically identify which repos belong to which ecosystem. Without them, even actively maintained repos are invisible to the tooling.

To add topics to your repository:

1. Go to your repository on GitHub

2. In the right-hand sidebar, find the About section

3. Click the ⚙️ gear icon next to it

4. In the Topics field, add the relevant topics from the table below

5. Click Save changes

Step 2: Add one attribution sentence to your README​

Electric Capital's tooling scans README files for signals that confirm a repo's relationship to an ecosystem. One sentence, placed near the top of your README, is sufficient. Please use exact wording from the table below. Customising the phrasing means the automated system may not recognize it.

Step 3: Open a PR to the Awesome dApps list​

The Midnight Awesome dApps list is the community-maintained directory of ecosystem projects. Opening a PR adds your project to that record and makes it discoverable by other developers, partners, and the teams evaluating the ecosystem.

Submit your project at: github.com/midnightntwrk/midnight-awesome-dapps.

Earn Zealy points while you're at it!​

Each of the three steps above has a corresponding quest on Zealy. Complete them to earn points and appear on the Midnight ecosystem leaderboard. Links to the three quests are below.

• Quest 1: Add the midnightntwrk GitHub topic

• Quest 2: Add the attribution sentence to your README

• Quest 3: Open a PR to the Midnight Awesome dApps list

Three steps, once per repo, permanent record​

These changes don't affect how your code works. They affect how your work is seen. Midnight's first public developer count will be used in every industry report, investor briefing, and ecosystem comparison that references the network for years to come. Your repo being in that count matters.

Questions? Find us in the Midnight Discord in #dev-chat, or reply to this post.

Midnight Testnet-02 has been a monumental success, serving as the crucible for Midnight’s zero-knowledge capabilities. We want to extend our deepest gratitude to the over 180+ Cardano Stake Pool Operators (SPOs) who actively participated in the Testnet-02 environment and their ongoing support for the Midnight project.

In previous communications, we signaled that SPOs would migrate directly to the Midnight Preview environment at this stage. However, as we refine the roadmap toward the Kūkolu (Federated Mainnet) phase, we have made a strategic pivot.

While Testnet-02 validators may continue to run their nodes until February 28, 2026, the Midnight Preview environment will be temporarily maintained by core engineering. This shift allows us to:

• Perform high velocity testing and rapid iterations.
• Finalize the integration of novel features such as the DUST Capacity Exchange.
• Ensure a stable, rapid-test environment for core development that would otherwise cause unnecessary disruption and downtime for independent SPOs.

This keeps the structure clean and focused on phases, milestones, and roles.

Please note: All dates are estimates.

We acknowledge that this change differs from previous expectations, but we believe this path ensures the highest quality environment for SPOs to return for Mōhalu.

Direct action on your feedback​

We recently conducted a feedback survey to understand your operational experience. We heard your feedback regarding documentation, setup friction, and infrastructure control. In preparation for the Mōhalu phase, we are implementing the following changes:

• We are moving away from a Docker-only distribution. We are now delivering pre-compiled binaries for midnight-node and restructuring our documentation to be binary and source-first. While containerization is useful, we recognize that barebones instructions are fundamental for professional SPO infrastructure.
• The next node version will completely remove the registration wizard, allowing for a more direct and scriptable registration process.
• We are prioritizing new architecture recommendation for secrets management and air-gapped signing guidance. We recognize that for a privacy-focused chain, the security of our validators' keys is paramount.
• In the lead up to Mōhalu, we promise more structued communication cadence and dedicated SPO/ validator calls.

Staying informed: Subscribe to Midnight Validator Updates​

👉 To ensure you receive the latest technical specifications, onboarding guides, and timeline adjustments for the Mōhalu phase, we encourage all SPOs to subscribe via the Midnight Validator Digest: https://mpc.midnight.network/midnight-validator-digest

👉 Join other validators and builders in the Midnight Discord server: https://discord.com/invite/midnightnetwork

Compact, Midnight's smart contract language, isn't in that training data. When you ask an AI assistant to write a Compact contract, it hallucinates. It invents syntax that doesn't exist, references functions that were never defined, and produces code that fails at compile time.

Midnight MCP solves this problem.

What is MCP?​

The Model Context Protocol (MCP) is an open standard that allows AI assistants to access external tools and data sources. Instead of relying solely on training data, an AI assistant with MCP can query live documentation, search codebases, and call APIs.

Midnight MCP is an MCP server purpose-built for Midnight development. It gives AI assistants:

• Indexed knowledge of 102 Midnight repositories
• Real compiler validation before showing you code
• Semantic search across documentation and examples
• Version-aware syntax references for Compact

When you ask Claude to write a Compact contract, it queries Midnight MCP for the correct syntax, generates the code, validates it against the real compiler, and only shows you working code.

The problem with AI-generated Compact code​

Consider this prompt:

"Write a simple counter contract in Compact"

Without Midnight MCP, an AI assistant might generate:

contract Counter {
    state count: Int = 0;

    function increment(): Void {
        count = count + 1;
    }
}

This looks plausible. It's also completely wrong:

• Compact uses ledger for state, not state.
• There is no Int type in Compact. It uses Uint<32>, Field, and other specific types.
• Void doesn't exist. Compact uses [] for the unit type.
• State mutations require witness functions, not direct assignment.

The AI hallucinated a language that resembles Solidity but isn't Compact. A developer unfamiliar with Compact might spend hours debugging code that was never valid.

Install Midnight MCP​

Midnight MCP requires no API keys and installs in under 60 seconds. Add the appropriate configuration to your AI assistant based on the tool you use.

Claude Desktop​

On macOS, edit ~/Library/Application Support/Claude/claude_desktop_config.json. Add the following configuration to enable Midnight MCP:

{
  "mcpServers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

Cursor​

Create or edit .cursor/mcp.json in your project root. You can also configure it globally at ~/.cursor/mcp.json on macOS/Linux or %USERPROFILE%\.cursor\mcp.json on Windows. Add the following configuration:

{
  "mcpServers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

VS Code with GitHub Copilot​

Create or edit .vscode/mcp.json in your project. Add the following configuration to connect Copilot to Midnight MCP:

{
  "servers": {
    "midnight": {
      "command": "npx",
      "args": ["-y", "midnight-mcp@latest"]
    }
  }
}

After adding the configuration, restart your AI assistant. You now have access to 29 Midnight-specific tools.

How Midnight MCP works​

Midnight MCP operates as a local server that connects your AI assistant to Midnight's ecosystem.

When you ask for a Compact contract:

1. The AI assistant calls midnight-get-latest-syntax to retrieve current Compact syntax.
2. It generates code using the correct patterns.
3. It calls midnight-compile-contract to validate against the real compiler.
4. If compilation fails, it reads the error, fixes the code, and retries.
5. You receive verified, working code.

This compile-validate-fix loop happens automatically. You never see the broken intermediate versions.

Real compiler integration​

Most code-generation tools rely on pattern matching and hope. Midnight MCP validates code against the actual Compact compiler hosted.

The compiler catches errors that static analysis cannot, including:

• Type mismatches: Using Field where Uint<64> is expected
• Sealed field violations: Attempting to access sealed state incorrectly
• Disclose rule errors: Missing or malformed privacy annotations
• Unbound identifiers: References to undefined variables or types

When the compiler returns an error, the response includes the exact line number and column:

success: false
message: "Line 12:8 - unbound identifier 'totalSupply'"
errorDetails:
  line: 12
  column: 8
  errorType: error

The AI assistant uses this information to fix the code and try again.

Graceful fallback​

If the hosted compiler is unavailable, Midnight MCP falls back to static analysis. The response indicates which validation method was used:

validationType: "compiler"           # Real compiler validation
validationType: "static-analysis-fallback"  # Compiler unavailable

You always receive validation. The tool never fails silently.

Semantic search across 102 repositories​

Today, Midnight MCP indexes every non-archived repository in the Midnight ecosystem:

• All 88 repositories from midnightntwrk.
• 14 community and partner repositories, including OpenZeppelin contracts and hackathon winners.

The search is semantic, not keyword-based. For example, a prompt like "find code that handles shielded transactions" returns relevant results even if those exact words don't appear in the code.

Prompt: "How do I implement a token with transfer limits?"

midnight-search-compact returns:
- Token contract examples from midnight-examples
- Rate limiting patterns from community repos
- Relevant documentation sections

29 tools for Midnight development​

Midnight MCP provides 29 tools organized by function.

Search tools​

Use these tools to find code, documentation, and examples across the Midnight ecosystem.

Analysis tools​

Use these tools to validate, analyze, and review Compact contracts.

Generation tools​

Use these tools to create new contracts and documentation.

Repository tools​

Use these tools to access files and syntax references from Midnight repositories.

Version management tools​

Use these tools to manage upgrades and track changes between Compact versions.

Resources and prompts​

Beyond tools, Midnight MCP provides nine built-in resources and five interactive prompts.

Resources are always-available references that provide quick access to syntax and examples:

midnight://syntax/latest      Current Compact syntax
midnight://examples/counter   Counter contract example
midnight://examples/token     Token contract example
midnight://docs/compact       Compact language reference

Prompts are templates for common tasks that guide you through specific workflows:

create-compact-contract      Start a new contract
debug-compact-error          Fix compilation errors
security-review              Full security audit
compare-compact-versions     Migration assistance

Architecture​

Midnight MCP is built for reliability:

• Token efficiency: Outputs YAML by default (20-30% fewer tokens than JSON)
• Compound tools: Single calls that combine multiple operations
• Graceful degradation: Falls back to cached data when services are unavailable
• Progress notifications: Real-time updates during long operations

The codebase is fully tested with 206 tests across 10 test suites.

What's next​

Midnight MCP is open source and actively developed. The roadmap includes:

• Full ZK circuit output parsing from compiler results.
• Contract deployment directly from AI chat.
• TypeScript SDK integration for automatic prover code generation.
• Local devnet interaction for querying balances and submitting transactions.

Learn more​

Explore the source code and contribute:

→ GitHub repository

→ npm package

→ API documentation

Midnight MCP is a community project. Contributions, issues, and feature requests are welcome.

• Night is like a Solar Panel. It is a valuable asset you hold.
• Dust is like Electricity. It represents the computational throughput or gas generated by the Solar Panel (Night).
• Usage. You consume the Electricity (DUST) as gas to power your operations on the network.

Unlike standard cryptocurrencies where you have a static balance (e.g., "I have 5 coins"), your Dust balance changes dynamically based on time and the status of your Night tokens.

Dust and network usage​

Dust operates similarly to, but separately from, Zswap. Dust operates as the resource credit system for Midnight. It function

• Shielded and Non-transferable: Dust is a shielded capacity resource only for gas. It cannot be transferred between users.
• Dynamic Capacity: The available gas in a Dust UTXO is dynamically computed and derived from an associated Night UTXO.
• Growth & Decay: The computed value grows over time to a maximum based on its Night UTXO, and decays to zero after its Night UTXO is spent.
• Non-Persistent: The system may redistribute it on hardforks. (Note: The Midnight protocol reserves the right to modify Dust allocation rules, e.g., for garbage collection).

Design overview​

Similar to Zswap, Dust is built on hashes and the commitment/nullifier paradigm. Each Dust UTXO has a commitment inserted into an append-only Merkle tree upon creation, and a nullifier inserted into a nullifier set upon spending.

A Dust "spend" is a 1-to-1 "transfer" (Self-Spend):

1. Input: 1 Dust UTXO (nullifier).
2. Output: 1 Dust UTXO (commitment).
3. Fee: A public declaration of fees paid.

It includes a zero-knowledge proof that:

1. The input is valid and exists in the Merkle tree.
2. The output value equals the updated input value minus the gas consumed.
3. The output nullifier is correct, and the owner remains the same.

Lifecycle: NIGHT generates DUST​

Conceptually, Dust is generated over time by held Night UTXOs. As long as a backing Night UTXO remains unspent, the associated Dust UTXO generates value up to a cap ($\rho$). Once the backing Night is spent, the Dust UTXO "decays" to zero.

The following diagram illustrates this lifecycle:

The rate of generation depends on the amount of night held ($N$), the ratio of the Dust cap to Night held ($\rho$), and "time to cap" ($\Delta$).

Spending Rules:

• Dust may be spent multiple times; a new UTXO is always created, even if its value is zero.
• Spending during decay is permitted and does not change the decay rate.
• Once the backing Night is spent, Dust immediately starts to decay, even if it was still in the generation phase.
• If only a portion of backing Night is spent, the change creates a new Night UTXO (starting fresh Dust generation), while the old Dust UTXO decays.

Implementation Note: In practice, value is not processed continuously. It is calculated at the time of spend using metadata ("generation info"):

1. Creation time of the Dust UTXO.
2. Creation time of the backing Night UTXO.
3. Deletion time of the backing Night UTXO.

Since Dust and Night use different keys, a Registration Table links Night public keys to Dust public keys. A new Dust UTXO is created if and only if a Night UTXO is created and its key has a table entry.

The Grace Period: Because Dust usage is shielded, the value is computed for the time of transaction creation. To account for network delays, the protocol defines a Dust Grace Period (for example, 3 hours). A transaction is accepted if its timestamp is within this window relative to the block time.

Preliminaries​

DUST uses ZK-friendly hashes.

type DustSecretKey = Fr;
type DustPublicKey = field::Hash<DustSecretKey>;

Dust UTXOs have owners, values, and nonces. Nonces evolve deterministically to enable wallet recovery.

• First Dust UTXO: Nonce derived from the originating Night UTXO intent hash.
• Subsequent Dust UTXOs: Nonce derived from the previous sequence number and owner's secret key.

struct DustOutput {
    initial_value: u128,   // Specks at creation
    owner: DustPublicKey,
    nonce: field::Hash<(InitialNonce, u32, Fr)>,
    seq: u32,
    ctime: Timestamp,
}

State components include the commitment tree, nullifier set, and root history:

struct DustUtxoState {
    commitments: MerkleTree<DustCommitment>,
    commitments_first_free: usize,
    nullifiers: Set<DustNullifier>,
    root_history: TimeFilterMap<MerkleTreeRoot>,
}

Initial DUST parameters​

• Night Unit: Star (1 Night = 10^6 Stars)
• Dust Unit: Speck (1 Dust = 10^15 Specks)

const INITIAL_DUST_PARAMETERS: DustParameters = {
    night_dust_ratio = 5_000_000_000; // 5 DUST per NIGHT
    generation_decay_rate = 8_267; // ~1 week generation time
    dust_grace_period = Duration::from_hours(3),
};

Dust actions​

Users influence Dust state via Intents.

struct DustActions<S, P> {
    spends: Vec<DustSpend<P>>,
    registrations: Vec<DustRegistration>,
    ctime: Timestamp,
}

Registrations and fees​

DustRegistration links a Night key to a Dust key.

• Registrations happen sequentially.
• If a registration transaction uses Night inputs that were not yet generating Dust (meaning that they had no previous registration), the system can "backdate" the registration to use the Dust those inputs would have generated to pay for the gas.

Generating DUST​

Night inputs/outputs trigger updates to a Dust Generation Tree.

• DustGenerationInfo: Stores the amount of Night, the owner, and the dtime (deletion time).
• Address Map: Links Night Addresses -> Dust Addresses.

struct DustGenerationInfo {
    value: u128,
    owner: DustPublicKey,
    nonce: InitialNonce,
    dtime: Timestamp, // Set to MAX if Night is unspent
}

Dust value and spends​

The value of a Dust UTXO is calculated based on four linear time segments:

1. Generating: From creation to Capacity (or Night spend).
2. Constant (Max): At capacity until Night spend.
3. Decaying: From Night spend until value hits zero.
4. Constant (Zero): Forever after.

The Spend transaction​

A DustSpend consumes a UTXO and creates a new one with updated value minus fees.

The validation logic (dust_spend_valid) ensures:

• commitment_merkle_tree contains the input.
• dust_spend.old_nullifier matches the derived nullifier.
• updated_value covers the fee.
• new_commitment is correctly formed.

Wallet recovery​

Wallets recover funds by:

1. Identifying owned Night UTXOs (the start of the chain).
2. Linearly searching for commitments corresponding to sequence numbers ($0, 1, 2...$).
3. Privacy: Wallets should query commitments using bit-prefixes (stochastic filtering) rather than exact lookups to preserve privacy against the indexing service.

The implementation​

DUST Generation from Cardano NIGHT Token — Full Process​

The generation of DUST from the Cardano NIGHT token (cNIGHT) is a cross-chain process managed by the Native Token Observation Pallet (pallet_cnight_observation) on the Midnight partner chain.

Summary of the full flow​

1/ User registers their Cardano reward address + DUST public key on Cardano.

2/ Any time a cNIGHT UTXO is created (received) or spent (sent) by that address, the event is broadcast.

3–4/ The Midnight pallet validates that exactly one valid registration exists and observes the cNIGHT activity.

5–6/ It determines whether it’s a receive (creation) or send (destruction) of cNIGHT → generates corresponding DUST creation or destruction event.

7–9/ All events in a block are batched, wrapped into a single system transaction via LedgerApi, and executed on the Midnight ledger.

→ Final result: DUST supply and UTXOs are updated 1:1 with cNIGHT movements on Cardano.

👉 Now that you have an overview of DUST, checkout the DUST spec on Github!

👉 Get involved in the code on Github!

Review the guide to get started.

1. Registration​

To participate, register at https://hacktoberfest.com/auth/.

All opportunities to contribute to Midnight’s open source ecosystem will be available through our Community Hub.

Participants are encouraged to submit six (6) high-quality pull or merge requests between October 1 and October 31 to earn the official Hacktoberfest digital badge.
Review our Contribution Guidelines before submitting any work.

2. Hacktoberfest Participation​

Look for issues labeled hacktoberfest or browse through issues submitted by other community members to find contribution opportunities.

• Docs: Submit pull requests to the Midnight Docs repository.
• Core Libraries: Submit pull requests to MidnightJs.
• No-code / Low-code: Create pull requests in the Community Hub using the submission template.

Once reviewed and approved, qualifying issues will be labeled hacktoberfest-accepted.

Have an idea others can contribute to? Create an issue in the Community Hub using the following templates:

• dapp-proposal
• content-proposal
• documentation improvement

To earn additional Midnight-specific rewards, visit our Zealy quests and complete the tasks under the Hacktoberfest Competition quest.

3. Rewards​

🎖️ Holopin Badge​

Receive the official Hacktoberfest digital badge for contributing to open source.

👕 Swag​

The first 10,000 participants who successfully complete six (6) accepted PRs/MRs will receive the official Hacktoberfest T-shirt. (Terms & Conditions apply.)

Top 3 on the Zealy Hacktoberfest leaderboard win a Midnight T-shirt.

🌳 Treenation Reward​

Every sixth PR/MR qualifying for a T-shirt will also trigger a Treenation tree-planting contribution, helping make the world a greener place.

4. Acceptable Contribution Types​

Contributions may include, but are not limited to:

• Code updates to MidnightJs
• Technical documentation
• User experience testing
• Technical blog posts or tutorials
• Case studies or written articles
• Copywriting or editing
• Translations
• Talks or presentations
• Event organization
• Podcasts or interviews
• Social media campaigns
• Blog or video content
• Graphic design or visual assets

Ready to start contributing?
Explore open issues on the Midnight Community Hub and make your mark this Hacktoberfest!

How to Contribute​

Ready to jump in? It's as simple as creating an issue.

Our Workflow: From Idea to Reality​

Step 1: The Community Board (Triage)​

All new issues land here for initial review. This board is public, so everyone can see what's being proposed.

• New: Your issue has been submitted and is awaiting review.
• In Triage: The triage committee is actively reviewing your submission for validity, clarity, and priority.
• Needs Discussion: The issue requires more feedback or clarification from the community or the original poster.
• Rejected: The issue is out-of-scope or invalid. We will always provide a clear explanation.

Once an issue is approved, it gets a triaged label and is automatically moved to the next stage.

Step 2: The Grab n' Go Board (Development)​

This board contains approved, ready-to-work-on tasks. It's the community's backlog!

• Ready: Triaged issues waiting for a contributor to pick them up. Look for labels like good-first-issue if you're new!
• In Progress: A contributor has assigned themselves the issue and is actively working on it.
• Done: The work is complete and the issue has been closed (this happens automatically when a linked PR is merged).

Choosing the Right Issue Template​

To help us categorize and review your ideas faster, please use the best template for your submission:

• 📝 Content Proposal: Suggest new articles, tutorials, or educational resources to engage the community.
• 💡 Feature Request/Suggestion: Propose new features or enhancements for our tools and processes.
• 🐛 Bug Report: Report any defects, errors, or unexpected behavior. Please include clear reproduction steps!
• 🌐 dApp Proposal: Share your vision for a new decentralized application, integration, or improvement.

Selecting a template automatically applies the right labels, helping our automation keep things organized.

Our goal is to foster a truly collaborative environment where the collective wisdom of our community helps us build more robust, community-driven solutions.

Why Now? The Developer Relations Perspective​

You might be asking, "Why is the Developer Relations (DevRel) team launching this?" That's a great question, and it gets to the very core of our mission!

At its heart, Developer Relations is about empowering developers.

The Community Board is a natural, powerful extension of this mission. Here’s why it’s so crucial for us:

1. Direct Feedback Loop: Before, collecting structured feedback could be spread across multiple channels. The Community Board centralizes this, giving us a clear, prioritized view of what matters most to you.
2. Transparency and Prioritization: You'll be able to see what other developers are asking for, upvote ideas you support, and even watch as issues move from "Under Review" to "Planned" to "Shipped." This transparency helps you understand our roadmap and how your contributions fit in.
3. Community-Driven Development: We genuinely believe that the best products are built in collaboration with their users. The board allows us to tap into the collective intelligence of our community, surfacing the most impactful ideas and validating them with real-world needs.
4. Building Stronger Relationships: By giving you a clear, actionable way to contribute, we hope to build an even stronger, more engaged community where everyone feels invested in our shared success.

• Part 1: Top-level Contract Structure
• Part 2: Circuits and Witnesses

This article looks at the on-chain runtime and how public ledger state updates happen in your DApp.

The Bulletin Board's post Circuit

In the previous parts we used the Bulletin Board example DApp to take a look at contract structure and the implementation of circuits and witnesses. We saw that a contract's exported circuits, such as post from the Bulletin Board example, had an outer "wrapper" that called the actual implementation. We will now take a look at that actual implementation.

Recall the Compact implementation of post:

export circuit post(newMessage: Opaque<"string">): [] {
  assert(state == State.VACANT, "Attempted to post to an occupied board");
  poster = disclose(publicKey(localSecretKey(), instance as Field as Bytes<32>));
  message = disclose(some<Opaque<"string">>(newMessage));
  state = State.OCCUPIED;
}

It reads the state field from the contract's public ledger state and asserts that the bulletin board is vacant. Then it calls the witness localSecretKey and uses the return value to derive poster, a commitment to the post's author. Finally, it updates three ledger fields (poster, message, and state).

We compiled the contract with version 0.25.0 of the Compact compiler. Note that this is a different version than the one used in parts one and two of this series. If you use a different version, the implementation details might be different. The implementation of post is in a JavaScript function called _post_0. Every line of this function has something new to learn about the way that Compact works, so we will go line by line through it. The first line of this function corresponds to the first line of the Compact circuit:

_post_0(context, partialProofData, newMessage_0) {
  __compactRuntime.assert(
    _descriptor_0.fromValue(
      Contract._query(
        context,
        partialProofData,
        [
          { dup: { n: 0 } },
          { idx: { cached: false,
                   pushPath: false,
                   path: [
                     { tag: 'value',
                       value: { value: _descriptor_9.toValue(0n),
                                alignment: _descriptor_9.alignment() } }] } },
          { popeq: { cached: false,
                     result: undefined } }]).value)
      ===
      0,
    'Attempted to post to an occupied board');

(Here and below we have reformatted the JavaScript code to fit better on screen. The only change is the indentation.) We will read this line of JavaScript from the inside out. The very first subexpression evaluated in the Compact post circuit is simply state, which is a read of the ledger's state field. This also must be the first thing evaluated in the JavaScript implementation. It is implemented by a call to a compiler-generated static method _query on the Contract class. (We will take a closer look at Contract._query in the next article in this series.)

Recall what is happening when _post_0 is executed in your DApp. The JavaScript code is running locally on a user's machine, with full access to private data from the witnesses it uses. After running the code, the proof server will be used to construct a zero-knowledge (ZK) proof that it did run that code. Then, a transaction will be submitted to the Midnight chain. If the chain verifies the proof, the public ledger state updates specified by the circuit implementation will be performed.

The Midnight node uses the Impact VM, a stack-based virtual machine, to perform public ledger state updates. This machine executes a program in a bytecode language called Impact. We use the same Impact VM to perform updates to a local copy of the public state when we are running your DApp's code locally before submitting a transaction.

The On-Chain Runtime and the Impact VM

The Compact runtime package includes an embedded version of the on-chain runtime. This is the exact same Rust code that is used to implement the Midnight ledger on the Midnight network nodes. For the Compact runtime, it is compiled to WebAssembly and imported as the on-chain runtime package. You can actually use this package directly in your DApp, though much of it is re-exported by the higher-level Compact runtime. Sometimes the Compact runtime provides wrapped versions that have a higher-level API (specifically, using JavaScript representations instead of the ledger's native binary representation).

The Impact VM performs public ledger state updates, immediately in your DApp's copy and later (when the transaction is run) on chain. There are a host of reasons to use the exact same VM:

• Transaction semantics will be identical.
• It saves engineering work to implement it (and update it and maintain it) once.
• We will need the Impact program to compute fees for the transaction.
• The ZK proof will be about this specific Impact program.

The Impact VM is a stack-based machine. Transactions operate on a stack of values, which are encoded in the ledger's binary representation. The transaction always starts with three values on the stack:

1. First (at the base of the stack), a context object for the transaction.
2. Second, an effects object collecting actions performed by the transaction.
3. Third, the contract's public state.

When a transaction completes, these three values are left on the stack in the same order. Values on the VM's stack are immutable. For instance, a state update is accomplished by replacing the state third on the stack with a new one (rather than mutating the existing state value).

The third argument to Contract._query is an array of Ops which are JavaScript representations of Impact VM instructions. Op is a type defined in the on-chain runtime. Transactions will use a binary encoding of these instructions. The array of instructions is a partial Impact program. A whole program will be built up for the transaction, usually with multiple calls to Contract._query.

Ledger Read Operations

The Impact code for the ledger read of the field state from above was:

[
  { dup: { n: 0 } },
  { idx: { cached: false,
           pushPath: false,
           path: [
             { tag: 'value',
               value: { value: _descriptor_9.toValue(0n),
                        alignment: _descriptor_9.alignment() } }] } },
  { popeq: { cached: false,
             result: undefined } }]

The first instruction is dup 0. Instructions will find their inputs on the Impact VM's stack. They can also have operands which are encoded as part of the instruction, such as the zero in dup 0.

The dup N instruction duplicates a value on the stack. The value is found N elements below the top of the stack, so N=0 is the top of the stack. Since this is the first Impact instruction in a post transaction, that will be the public ledger state value.

Before dup 0, the Impact VM's stack had <context effects ledger0> in order from the base to the top of the stack. ledger0 is the initial ledger state of this transaction. After dup 0, it will have <context effects ledger0 ledger0> with two copies of the ledger state on top of the stack. This allows subsequent instructions which consume values to execute without losing the public ledger state.

The second instruction is idx [0]. This instruction indexes into the top value on the stack, extracting a subpart of it. It removes the top value on the stack and replaces it with the extracted subpart. The instruction's operand is a path, a sequence of ledger-encoded values (or a special tag stack). The two different encodings of values, and the descriptors that convert between them, were described in Part 2. Here the instruction uses _descriptor_9:

const _descriptor_9 = new __compactRuntime.CompactTypeUnsignedInteger(255n, 1);

This is an instance of CompactTypeUnsignedInteger from the Compact runtime. It takes a maximum value and a size in bytes. So this is the descriptor for a one byte unsigned integer with a maximum value of 255 (that is, just an unsigned byte). The value 0n is the public ledger state index that the Compact compiler has assigned to the state field.

Impact has four different indexing instructions: idx, idxc (cached), idxp (push path), and idxpc (push path, cached). In the JavaScript representation of instructions, we simply use a pair of boolean properties giving the same four variants. cached is true when the value being accessed has already been accessed (that is, read or written) in the same transaction. It can potentially be used for assigning different fees for cached and uncached accesses. In this case, we have not accessed the state ledger field yet in the transaction. pushPath is a variant that leaves a path in place on the stack for a subsequent write operation.

Before idx [0], the VM's stack had <context effects ledger0 ledger0>. After idx [0], it will have <context effects ledger0 state> (where ledger0 is the entire public ledger state and state is the value of the field with that name).

The third instruction is popeq. This instruction pops the top value from the VM's stack. The Impact VM can run in two different modes. It runs in gathering mode when it runs locally in a DApp. It runs in verifying mode when it executes a contract's public ledger state updates on chain. In gathering mode the popped value is collected (it's used by Contract._query as the result of this ledger read). In verifying mode the VM will ensure that the popped value is equal to the instruction's operand. Here we are running in gathering mode, so the instruction's result operand is the JavaScript undefined value.

Before popeq, the VM's stack had <context effects ledger0 state>. After popeq, it will have <context effects ledger0>.

These three simple VM instructions implement a top-level ledger read.

Assert in Circuits

The post circuit asserts that the bulletin board's state is vacant. This is implemented by the JavaScript code from above (with the Impact instructions elided):

__compactRuntime.assert(
  _descriptor_0.fromValue(
    Contract._query(
      context,
      partialProofData,
      /* Impact code */).value)
    ===
    0,
  'Attempted to post to an occupied board');

Contract._query returns an object with a ledger-encoded result. _descriptor_0 is the descriptor for the the State enumeration type, so _descriptor_0.fromValue is used to convert it to one of the enumeration values VACANT=0 or OCCUPIED=1. This value is compared via JavaScript's strict equality operator to the vacant value (zero). The assertion itself is implemented by a call to the Compact runtime's assert function. If the condition is not true, this will cause the DApp's post transaction to fail without ever reaching the Midnight chain.

Provided that the assertion succeeds when running the DApp locally, the ZK proof will prove that it suceeded. When the proof is verified on chain, the Midnight network will then know that this assertion was true.

The on-chain Impact program will not directly assert this property (that state was State.VACANT). However, when the popeq instruction is run in verifying mode, it will have an operand that indicates the actual value that was popped locally in the DApp. So specifically, if the DApp successfully built a post transaction, that instruction will be popeq 0.

This is subtly different from asserting that the state field was 0. If the assert were removed from the Compact program and the ledger field read remained, then the Impact program run on chain could have either popeq 0 or popeq 1 depending on the actual value that was read by the DApp.

Circuit and Witness Calls

The second line of the Compact post circuit is:

poster = disclose(publicKey(localSecretKey(), instance as Field as Bytes<32>));

This is a write to the ledger's poster field. The right-hand side of the write operation is implemented by the JavaScript code:

const tmp_0 = this._publicKey_0(
  this._localSecretKey_0(context, partialProofData),
  __compactRuntime.convert_bigint_to_Uint8Array(
    32,
    _descriptor_1.fromValue(
      Contract._query(
        context,
        partialProofData,
        [
          { dup: { n: 0 } },
          { idx: { cached: false,
                   pushPath: false,
                   path: [
                     { tag: 'value',
                       value: { value: _descriptor_9.toValue(2n),
                                alignment: _descriptor_9.alignment() } }] } },
          { popeq: { cached: true,
                     result: undefined } }]).value)));

The compiler has named this value tmp_0 so it can refer to it later.

The call to the witness localSecretKey has been compiled into a call to the _localSecretKey_0 method of the contract. Recall from Part 2 that this method is a wrapper around the DApp-provided witness implementation. The wrapper performs some type checks on the witness return value, and it records that return value as one of the transaction's private inputs.

The Impact code above implements the read of the ledger's instance field. It is nearly the same as the code for the read of state. The difference is that the Compact compiler has assigned instance to index 2.

The field instance has a Counter ledger type. Reading it in Compact gives a Uint<64>. The ledger representation of this value is converted to the JavaScript representation (bigint) using _descriptor_1:

const _descriptor_1 = new __compactRuntime.CompactTypeUnsignedInteger(18446744073709551615n, 8);

The maximum value here is the maximum unsigned 64-bit integer and the size in bytes is 8.

Type Casts in Compact

The Compact code has a sequence of type casts instance as Field as Bytes<32>. instance is a Counter, reading it from the ledger gives a Compact value with type Uint<64>. This cannot be directly cast to Bytes<32> so the contract uses an intermediate cast to Field.

There are three distinct kinds of type casts in Compact: upcasts, downcasts, and so-called "cross casts". An upcast is from a type to one of its supertypes. Such a cast will change the static type as seen by the compiler, but it will have no effect at runtime. For example, casting from Uint<64> to Field is an upcast. That cast was performed statically (that is, by the compiler) but there is no JavaScript code here to implement it. A downcast is from a type to one of its subtypes. Such a cast will not normally change a value's representation, but it will require a runtime check in the compiler-generated JavaScript code. A cross cast is from a type to an unrelated type (with respect to subtyping). For example, casting a Field to Bytes<32> is a cross cast. These type casts will normally require a representation change. The Compact runtime function convert_bigint_to_Uint8Array performs the representation change in this case.

Then there was a call in Compact to the circuit publicKey. Here we see that the call goes directly to the JavaScript implementation method _publicKey_0, and not to the exported circuit's publicKey wrapper. Recall from Part 2 that the circuit wrapper performed some runtime type checks that we do not need when we call from Compact to Compact (the Compact type system guarantees that these checks aren't needed). More importantly, a circuit's wrapper established a fresh proof data object for a transaction. Since the call to publicKey is part of the post transaction that the DApp is building, it should reuse the existing proof data.

Notice that the disclose operator in Compact doesn't do anything at all at runtime. disclose was necessary because a value computed from the witness localSecretKey was exposed on chain. This is an instruction to the Compact compiler to allow this value to be exposed, but it has no runtime effect.

Ledger Writes

The right-hand side value named tmp_0 in JavaScript should be written to the ledger field poster. The code to do that is in the next line of JavaScript code:

Contract._query(
  context,
  partialProofData,
  [
    { push: { storage: false,
              value: __compactRuntime.StateValue.newCell(
                { value: _descriptor_9.toValue(3n),
                  alignment: _descriptor_9.alignment() }).encode() } },
    { push: { storage: true,
              value: __compactRuntime.StateValue.newCell(
                { value: _descriptor_2.toValue(tmp_0),
                  alignment: _descriptor_2.alignment() }).encode() } },
    { ins: { cached: false, n: 1 } }]);

This is again implemented by a partial Impact program. The Impact code above implements a ledger cell write (in contrast to the read we saw above).

The first instruction is push 3. Impact's push instruction is the dual to the pop instruction. Impact has two different variants: push and pushs. In the JavaScript representation of Impact instructions, they are distinguished by a boolean storage property. storage is false to indicate that the value is kept solely in the Impact VM's memory and will not be written to the ledger.

The second instruction is pushs tmp_0. The instruction is pushs because storage is true (this value will be written to the ledger). The instruction's operand will be the actual Bytes<32> value of tmp_0. As you would expect, _descriptor_2 is the descriptor for Bytes<32>, used to convert the JavaScript value to a ledger value:

const _descriptor_2 = new __compactRuntime.CompactTypeBytes(32);

Before executing these two instructions, the Impact VM's stack had <context effects ledger0>. After executing these two instructions, it will have <context effects ledger0 3 tmp_0>.

The next instruction is ins 1 which inserts into a value on the VM's stack. Impact's ins instruction is the dual to the idx instruction we saw used for ledger reads. The value to insert is on top of the stack (that is, the Bytes<32> value of tmp_0). Underneath that is a path consisting of N elements, where N is the operand of the ins instruction. In this case, the path has length 1, so it is the singleton sequence [3]. This is the index the Compact compiler has assigned to the top-level ledger field poster.

The insert instruction removes the value under the path (namely, the public ledger state) and replaces it with a new copy of that value with the location denoted by the path updated to have the new value.

Before ins 1, the Impact VM's stack had <context effects ledger0 3 tmp_0>. After ins 1, it will have <context effects ledger1> where ledger1 is a new public ledger state representing the write to poster.

The remainder of _post_0 has two more ledger writes and a return of the Compact empty tuple represented by the JavaScript empty array:

const tmp_1 = this._some_0(newMessage_0);
Contract._query(
  context,
  partialProofData,
  [
    { push: { storage: false,
              value: __compactRuntime.StateValue.newCell(
                { value: _descriptor_9.toValue(1n),
                  alignment: _descriptor_9.alignment() }).encode() } },
    { push: { storage: true,
              value: __compactRuntime.StateValue.newCell(
                { value: _descriptor_5.toValue(tmp_1),
                  alignment: _descriptor_5.alignment() }).encode() } },
    { ins: { cached: false, n: 1 } }]);
Contract._query(
  context,
  partialProofData,
  [
    { push: { storage: false,
              value: __compactRuntime.StateValue.newCell(
                { value: _descriptor_9.toValue(0n),
                  alignment: _descriptor_9.alignment() }).encode() } },
    { push: { storage: true,
              value: __compactRuntime.StateValue.newCell(
                { value: _descriptor_0.toValue(1),
                  alignment: _descriptor_0.alignment() }).encode() } },
    { ins: { cached: false, n: 1 } }]);
return [];

Take a look and see if you can see how the code above works.

publicKey

There is one more way that the on-chain runtime is used by Compact. If we take a look at the implementation of the publicKey circuit (the actual implementation, not the wrapper for the exported circuit):

_publicKey_0(sk_0, instance_0) {
  return this._persistentHash_0([new Uint8Array([98, 98, 111, 97, 114, 100, 58, 112, 107, 58, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]),
                                 instance_0,
                                 sk_0]);
}

We see that the padded string literal has been compiled to an explicit Uint8Array. We also see a call to a _persistentHash_0 method, which is the Compact standard library's persistentHash circuit.

The compiler has included a JavaScript implementation of this circuit:

_persistentHash_0(value_0) {
  const result_0 = __compactRuntime.persistentHash(_descriptor_7, value_0);
  return result_0;
}

This is a call to the Compact runtime's persistentHash function. This function in the Compact runtime is a thin wrapper around the on-chain runtime's own persistentHash. The difference is that the on-chain runtime's version operates on the ledger encoding of values, and the Compact runtime's version uses the descriptor it is passed to do the relevant conversion.

So this is the final capability of the on-chain runtime that we will look at here: it contains implementations of functions like persistentHash that are shared between the DApp and the Midnight node.

In the next article in this series, we will look at how partial Impact programs get collected together and how the compiler-generated JavaScript code produces so-called public inputs and public outputs for the ZK proof that will be generated.

Midnight is a privacy-first blockchain designed to bring privacy to decentralized applications. It achieves this through zero-knowledge proofs, programmable data protection, and developer-friendly tools like Compact, a TypeScript-based DSL (Domain-Specific Language) for writing privacy-aware smart contracts.

OpenZeppelin is renowned in the Ethereum ecosystem for its battle-tested smart contract libraries, which have secured trillions in on-chain value. Recently, OpenZeppelin partnered with Midnight to bring comparable tooling to the Compact ecosystem, adapting familiar standards like ERC-20 into privacy-preserving variants.

In the Ethereum world, the ERC-20 standard defines a fungible token with public ledger functions like balanceOf, transfer, approve, etc. It exposes transaction data transparently and lacks built-in privacy. The FungibleToken contract on Midnight draws inspiration from this, but operates within Midnight’s zero-knowledge, selective-disclosure framework.

Fungible tokens are a cornerstone of the blockchain ecosystem, representing digital assets that are interchangeable – much like traditional currency. On various blockchains, these tokens power a wide array of applications, from facilitating seamless transactions and enabling decentralized finance (DeFi) protocols to representing ownership in digital communities and driving the mechanics of in-game economies.

Unlike unique non-fungible tokens (NFTs), the value of one fungible token is identical to another of the same type, making them ideal for use cases requiring divisibility and ease of exchange. Their widespread adoption underscores their importance in building liquid and interconnected digital economies.

In this article, you'll learn about the core features of the contract, including how it manages ledger state variables, its key entry points and circuits for operations like minting, burning, and transferring tokens, and the essential safety and utility functions provided by the Utils and Initializable modules.
By understanding how these components fit together, you’ll gain insight into how the FungibleToken contract balances fungibility, usability, and privacy, providing an essential building block for privacy-preserving DeFi, identity, and tokenized assets on Midnight.

Features of the FungibleToken Contract​

The FungibleToken contract on Midnight utilizes ledger state variables to keep track of balances, allowances, total supply, name, symbol, and decimals. Its functionality is exposed through "circuits" (entry points) like Mint, Burn, Transfer, Approve, TransferFrom, and Initialize, all of which enforce specific zero-knowledge validated transitions and maintain the integrity of the token's state.

Ledger State Variables​

In Compact, the contract defines a structured state storing token balances and allowances—similar to ERC-20. The _balances map keeps track of the users’ token balances and is updated when a transfer occurs. The _allowances map keeps track of the permission given to specific users to spend tokens on behalf of another user:

export ledger _balances: Map<Either<ZswapCoinPublicKey, ContractAddress>, Uint<128>>;
export ledger _allowances: Map<Either<ZswapCoinPublicKey, ContractAddress>, Map<Either<ZswapCoinPublicKey, ContractAddress>, Uint<128>>>;

These values live in the contract's ledger and are updated through transactions sent to the contract.

There are other values in the ledger that are set when the contract is deployed:

export ledger _totalSupply: Uint<128>;
export sealed ledger _name: Opaque<"string">;
export sealed ledger _symbol: Opaque<"string">;
export sealed ledger _decimals: Uint<8>;

These values provide different information about the token managed by the contract, its total supply, its name, its symbol, and its decimal (for display).

Entry Points and Circuits​

In Compact, entry points are defined as circuits (akin to Solidity functions), each modelling a zero-knowledge validated transition. The difference between a circuit entry point and a circuit is that the entry point is callable via a transaction, while the non-entry point circuit is internal. Core circuits include:

• Mint / Burn (to mint new tokens or burn existing tokens).

• Transfer: to move tokens between addresses.

• Approve, TransferFrom: standard ERC-20-style delegation mechanisms.

• Initialize: via the Initializable module for contract setup.

Each circuit enforces necessary constraints — for example, ensuring sufficient balance, managing allowance decrements, and preserving total supply.

In the next step of the contract lifecycle, the different metadata stored in the ledger of the contract are safely initialized.

Initialization and Metadata**​

The following circuits define the essential setup and retrieval logic for the fungible token metadata and users’ balances, enforcing correct initialization.

• initialize(name_, symbol_, decimals_)
  One-time setup. Calls Initializable_initialize(), then stores the (disclosed) name, symbol, and decimals. Every other public circuit asserts that the contract is initialized first.

• name() / symbol() / decimals() / totalSupply()
  Simple getters that first assert initialized, then return the sealed (read only) ledger values.

• balanceOf(account)
  Safe map lookup that returns 0 if the account isn’t present (to prevent contract failure if the key is absent).

The Transfer Family​

The FungibleToken contract's transfer circuits manage token movement. Key circuits include: transfer for safe user-initiated transfers, _unsafeTransfer for internal token movement, _transfer for administrative transfers, _unsafeUncheckedTransfer for low-level token movement, and _update as the central accounting function for all token operations.

These are split into safe and unsafe variants because sending to contract addresses is currently disallowed (until contract-to-contract interactions are supported).

“Safe” circuits enforce that policy; “unsafe” ones let you bypass it—explicitly marked as dangerous in comments.

• transfer(to, value) → Boolean
  Safe user-initiated transfer: rejects if to is a ContractAddress. Internally, it just forwards to the unsafe variant after the check.

• _unsafeTransfer(to, value) → Boolean
  Owner is the caller (left(ownPublicKey())). Moves value using the unchecked internal mover, then returns true.

• _transfer(from, to, value) → []
  Admin/extension hook that moves tokens from an arbitrary from (not necessarily the caller). Still enforces the “no contracts as to” rule and then uses the same mover underneath.

• _unsafeUncheckedTransfer(from, to, value) → []
  The low-level mover checks that neither side is the zero/burn address and then delegates the actual accounting to _update.

• _update(from, to, value) → []
  Central accounting function used by all mint/burn/transfer paths. It’s an internal circuit; it cannot be called via a transaction.

  • If from is zero, the mint circuit is called, it asserts no uint128 overflow, and increases _totalSupply.

  • Else, it deducts from from balance (or reverts on insufficient funds).

  • If to is zero, the burn circuit is called, and it decreases _totalSupply.

  • Else, it adds to to balance.
    This single function guarantees the invariants for every movement of value.

The "transfer family" circuits ensure secure token movement, with "safe" variants disallowing transfers to contract addresses and "unsafe" variants providing lower-level control.
This leads us to explore how allowances function, enabling delegated token spending.

Allowances (approve / spend / transferFrom)​

This section details the allowance mechanisms within the FungibleToken contract, which enable users to delegate spending permissions to other addresses. These circuits facilitate secure, approved transfers on behalf of an owner without directly exposing their private keys.

• allowance(owner, spender)
  Read the nested _allowances map, returning 0 when keys are missing (no revert).

• approve(spender, value) → Boolean
  The owner is the caller. Forwards to _approve(owner, spender, value) and returns true.

• transferFrom(from, to, value) → Boolean
  Safe delegated transfer: enforces the “no contract receiver” rule, then defers to _unsafeTransferFrom.

• _unsafeTransferFrom(from, to, value) → Boolean
  The spender is the caller. First spends allowance via _spendAllowance(from, spender, value), then moves value using _unsafeUncheckedTransfer. Returns true.

• _approve(owner, spender, value) → []
  It ensures that both the owner and the spender are valid, creates the owner’s entry in the map if needed, and then writes the allowance. (This mirrors OZ’s ERC-20 pattern of public approve() → internal _approve().)

• _spendAllowance(owner, spender, value) → []
  It deducts from the allowance unless it’s “infinite.” The implementation treats MAX_UINT128 as infinite: if currentAllowance == MAX, it doesn’t decrement; otherwise, it asserts currentAllowance ≥ value and writes back currentAllowance - value.
  This is important because it supports “no-friction approvals” by letting apps set MAX once.

So, we just covered how allowances let people delegate token spending—basically, giving others permission to move their tokens. Up next, we'll dive into how we create and delete tokens in the contract.

Minting and Burning​

Here's how the FungibleToken contract handles making and destroying tokens. We'll dive into the _mint and _burn functions, showing what they do and how they link up with the main accounting system.

• _mint(account, value) (safe) → []
  It forbids minting to a contract address (same contract-to-contract restriction), then forwards to _unsafeMint.

• _unsafeMint(account, value) → []
  It validates the receiver’s address, then calls _update(burnAddress(), account, value)—i.e., mint is modelled as a transfer from the burn/zero address.

• _burn(account, value) → []
  It validates the sender’s address, then calls _update(account, burnAddress(), value)—i.e., burn is a transfer to the burn/zero address.
  Note: The actual notion of “zero/burn” address is standardized in the Utils module; you can also see helpers like Utils_isKeyOrAddressZero and Utils_isContractAddress.

Because mint and burn also route through _update, total supply is adjusted in exactly one place, and the same safety checks apply across all flows (including the uint128 overflow check on mint).

The mint and burn circuits, by using the _update function, make sure the total supply adjustments are always consistent and that all token flows get the same safety checks.
Now, let's dive into the extra safety and utility stuff that the Utils and Initializable modules bring to the table.

Safety and Utility Glue (from Utils and Initializable)​

This section explores how the Utils and Initializable modules provide essential safeguards and helpful functionalities. These components are vital for ensuring the contract's integrity and enabling secure, well-managed operations.

• Initialization guards: The Initializable_initialize and Initializable_assertInitialized functions serve as crucial initialization guards within the Initializable contract. These safeguards ensure that a contract's state is properly set up only once and that subsequent operations only proceed if the contract has been correctly initialized. Every circuit that interacts with or modifies the contract's state is designed to invoke the assert function, reinforcing the integrity of the initialization process.

• Address helpers:

  • Utils_isContractAddress(either) distinguishes user keys from contract addresses.

  • Utils_isKeyOrAddressZero(either) detects the zero/burn address used in _update, _unsafeUncheckedTransfer, etc.
    These support the temporary “no contract receiver” policy and zero-address checks.

The Utils and Initializable modules provide crucial safety and utility functions, ensuring the contract's proper setup and secure operation. Now, let's look at how all these different parts of the FungibleToken contract work together.

How the Pieces Fit Together​

This part shows how everything in the FungibleToken contract is hooked up. Whether it's you sending tokens, someone else doing it for you, or tokens being created or destroyed, it all funnels through a few key functions and ultimately lands in the main _update function to keep track of everything.

• User transfer:
  transfer → (safe check) → _unsafeTransfer → _unsafeUncheckedTransfer → _update (balances/supply)

• Delegated transfer:
  transferFrom → (safe check) → _unsafeTransferFrom → _spendAllowance → _unsafeUncheckedTransfer → _update

• Mint/Burn:
  _mint/_unsafeMint or _burn → _update (with zero/burn address on one side)

This section illustrates how various token operations, from user transfers to minting and burning, ultimately funnel through the central _update function for consistent accounting. Now, let's summarize the key takeaways of the FungibleToken contract on Midnight.

Conclusion​

The FungibleToken Compact contract on Midnight is a privacy-aware reimagining of the ERC-20 standard. It maintains the familiar token interfaces—balances, transfers, approvals—but encodes them as ZK-validated circuits within Compact, enabling private, verifiable execution. The contract’s state and logic are shielded by design, exposing only proofs rather than raw data to the blockchain.

The ERC-20 standard revolutionized the crypto landscape by providing a common framework for creating and managing digital assets, fostering interoperability, and accelerating the growth of decentralized applications. For Midnight, an ERC-20-based token is crucial as it leverages this established standard while integrating ZK-privacy, offering a familiar yet enhanced experience for developers and users seeking both functionality and confidentiality.

This model contrasts sharply with ERC-20 on Ethereum, where all token movements and balances are fully transparent. Here, Midnight allows selective disclosure: users and applications choose what to reveal. The FungibleToken contract thus balances fungibility, usability, and privacy—providing an essential building block for privacy-preserving DeFi, identity, and tokenized assets on Midnight.

Links​

Delve deeper into the code, contracts, and comprehensive documentation to enhance your understanding and development skills. These resources are invaluable for building robust and innovative solutions.

• FungibleToken contract: FungibleToken.compact on Github
• OpenZeppelin documentation: docs.openzeppelin.com
• ERC20 standard: ethereum.org
• Midnight docs: Midnight Developer Documentation
• Do you have any questions?: Midnight Forum

I had recently left my software engineering role to explore zero-knowledge protocols, an area in which I didn’t have much experience. It was a risk, but one I felt I had to take. I chose to pursue this path not only because zero-knowledge cryptography is built on one of the most elegant branches of mathematics, but also I believe privacy on the blockchain or on the internet is fundamental and should never be an afterthought.

One day, my mentor casually mentioned the African Blockchain Championship and suggested I look into the Zero-Knowledge track. That small nudge became a turning point.

That’s when I discovered Midnight!

Meet Midnight: Privacy on the Blockchain

Midnight is a zero-knowledge proof-based privacy chain developed by Input Output, the parent company of Cardano. As a partner chain of Cardano, it aims to bring rational privacy through zero-knowledge technology to the broader ecosystem. They weren’t just building another blockchain—they were laying the foundation for private, decentralized computation. After diving into the documentation and setting up the tools, everything was finally in place. All that remained… was to begin. Only later did I realize: this wasn’t just the start of another hackathon—it was the beginning of something much bigger.

Building on Midnight

Hacking on Midnight was challenging, as building in a testnet environment requires constant learning and adaptation to major changes. Within just a few weeks, significant network updates rendered the existing examples incompatible with the latest SDK versions. As a result, an example had to be cloned and debugged line by line. The example repository was dense, filled with layers of files and directories, and figuring out where to start was a challenge in itself.

Fortunately, Midnight’s smart contract language, Compact, shares a syntax similar to TypeScript, which eased the learning curve. I pushed forward, determined to build something meaningful and make my mark—but in the end, my attempt fell short. With midterm exams approaching and the hackathon submission deadline close by, I had to make a difficult decision. I decided not to submit a project to the African Blockchain Championship hackathon. Still, a quiet sense of regret lingered. I couldn’t help but wonder: what if I had just pushed a little harder?

The Extended Deadline

About a week later, I received an email from the ABC team announcing that the hackathon deadline had been extended. I was thrilled, and I promised myself I’d give it everything this time. It wasn’t long before I was back at it. A few weeks had passed since I’d last touched the project, and during that time, both the network and SDKs had been updated. I gathered my gear, updated my environment, and set out with renewed determination to finally build something solid. I wrote my contract and began debugging, but each change introduced a new layer of complexity. Every update required changes across multiple files. It was frustrating, exhausting, but strangely thrilling. I began thinking of ways to simplify the chaos, to make the process less painful, more intuitive. That’s when I started creating small scripts to streamline the workflow.

Earlier that month, I had joined the Midnight Discord to ask questions. One week, I jumped on a Discord community call, and to my surprise, I learned about an ongoing Midnight tooling hackathon that was happening asynchronously. Right then, it clicked: this was the hackathon I was meant to be part of from the start.

From Personal Tool to Shared Project

What started as a personal tool suddenly took on a bigger purpose. The hackathon provided me with the opportunity to share my work with others and contribute to shaping the future of smart contract development on Midnight. I took a little detour from my original hackathon submission—promising myself I’d return to it—and began refining the tool, aiming not just to build something functional, but something genuinely useful for newcomers to the ecosystem.

Scaffold Midnight & Create Midnight App​

That’s how Scaffold Midnight was born, a cloneable GitHub starter template. But I didn’t stop there. I realized it would be even more useful as an npm library, something developers could install with all dependencies bundled and start using right away. So, I polished the project and released the first version as create-midnight-app. But I didn’t want to stop at solving just one problem. Every issue I fixed revealed another. Through multiple iterations, I kept refining the library. It’s now at version 2.1.7, and I’m actively working to make it compatible with the latest release of Compact. It’s far from perfect, and that’s what makes it exciting. Every day, I wake up with a new idea, a new feature to add, or a better way to improve the developer experience!

At its core, create-midnight-app is a scaffolding npm library for Midnight that automates the entire setup process. Developers can focus solely on writing their Compact contracts; the tool takes care of the rest. It handles wallet creation, faucet requests, balance checks, API configuration, CLI updates, and even function and file change imports are updated automatically. It reduces initial application setup time from over half an hour to just a few minutes.

I had several euphoric moments while working on this project, but one instance in particular, stands out.

One feature I was eager to build was a way for developers to request testnet tokens without ever leaving their code editor. The simplest idea was to send a request from the terminal directly to the official Midnight faucet. But there was a catch—the site is protected by Cloudflare Turnstile, which blocks automated requests to prevent spam and abuse. As a hacker, I started looking for a workaround. After some Googling and tips from friends, I tested several paid tools that claimed to bypass CAPTCHA protections. I spent an entire afternoon trying them, but none worked reliably. That’s when I remembered the genesis wallet, whose private key is publicly available. So, I implemented a workaround: instead of calling the faucet, I simulated a faucet transaction by transferring tokens directly from the genesis wallet to the user’s wallet. It’s not a long-term solution, and I know it won’t scale—but for now, it works and helps streamline the developer experience.

Submission and Recognition

I finally submitted my project, and the judges’ reactions were incredibly encouraging—it gave me a renewed sense of inspiration. With that momentum, I turned my focus back to my original hackathon: the African Blockchain Championship. For this challenge, I built an anonymous, censorship-resistant voting platform. In many African countries—across 34 nations—roughly 30–40% of citizens no longer view voting as a fair or trustworthy process (Afrobarometer, 2023). That’s why anonymous voting isn’t just a feature—it’s a necessity. My project, Privote, aims to address this critical issue by leveraging zero-knowledge technology to protect voter identity and integrity.

As the submission deadline approached, I ran into a major hurdle: integrating the wallet into the frontend. I reached out to one of the Developer Relations Engineers, who kindly shared some example code. Unfortunately, I couldn’t get it working in time. With the clock ticking, I had to improvise. I quickly built a custom Chrome extension that enabled wallet interaction—running through the terminal on the backend—just in time for submission. While the current version still has some privacy limitations, the smart contract compiles successfully, and users can interact with it on the Midnight testnet—offering a real glimpse of what decentralized, anonymous voting could look like in practice.

The Midnight Community

Even though there aren’t many resources available yet, the Midnight community more than makes up for it. Almost every question asked on Discord gets a response. It’s a space where people genuinely support each other—even during hackathons, when we’re technically competing and have little incentive to help other teams. In fact, during the hackathon, I often found myself answering questions in the Telegram group. I even hosted a workshop at the ABC hackathon on how to use Create Midnight App, helping others get started quickly and navigate the ecosystem more easily.

I also want to take a moment to thank the Midnight team for the recognition they gave me—it truly meant a lot. Beyond placing first in the CLI track, the support and appreciation I received from the community were genuinely heartwarming. I even had the chance to join a community call—not just as a participant this time, but as a speaker—to share my journey and the lessons I’d learned along the way.

Why Now is the Time to Build on Midnight

And for you—my readers—this is honestly the best time to get involved in the Midnight ecosystem. There’s almost always a hackathon happening (seriously, it's kind of wild!). Right now, they’re even running a mini DApp hackathon. It’s an excellent opportunity to learn, build, and get your project noticed.

As for me, I’m currently building something new for the hackathon. While I enjoy working on projects, I’ve found even more fulfillment in developing infrastructure tools. I have a long-term goal of building a web-based Midnight playground where anyone can start writing Compact code and begin interacting with the Midnight testnet without needing to install anything. I hope to continue collaborating with the Midnight team and growing my skills—especially in zero-knowledge protocols—as I continue this journey.

To avoid confusion, we will make a careful distinction between the "Compact toolchain" and the "Compact developer tools". The toolchain contains the compiler and will eventually contain other tooling that is specific to a particular version of the Compact language. The developer tools include the updater tools and will eventually support other tools that work consistently across different versions of the language. In the initial release, the Compact developer tools are primarily used to manage the installation of a Compact toolchain, but they will support additional tooling in the future.

There is no new release of the Compact toolchain yet, but you can already start using the new developer tools to install and invoke the current version of the compiler.

The Old Toolchain Installation Method

Before this new release, installing the Compact toolchain was a manual and tedious process:

1. Developers had to download a ZIP file for a specific compiler version and platform architecture
2. They then had to extract it to a directory included in their PATH
3. On macOS, they would have to give permission to run the two different binaries (the compiler and the ZK-key generator).

This process would have to be repeated each time there was a new Compact toolchain release. Keeping multiple versions installed at once was also cumbersome and hard to manage.

The New Toolchain Installation Method

The new way to install the Compact toolchain starts with a one-time installation of the compact command-line tool. Once installed, the developer tools can update themselves automatically. To install, run the following command:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/midnightntwrk/compact/releases/latest/download/compact-installer.sh | sh

This command will download and run a shell script. It will instruct you how to add the binary directory it uses to your PATH environment variable.

Once you've done this, the compact command line tool is available to use. This tool has a number of useful subcommands that can be invoked. For instance, to update the toolchain to the latest version, you will run the command:

compact update

The output will look something like this (on an Apple Silicon macOS machine, for instance):

compact: aarch64-darwin -- 0.24.0 -- installed
compact: aarch64-darwin -- 0.24.0 -- default.

This subcommand will switch to the latest version of the toolchain available for your architecture. As of today, this is version 0.24.0 which is reported by the tool. The compact tool will download the toolchain artifacts if necessary (you will see a progress meter while it downloads). If you have already downloaded the artifacts, the tool will simply switch the default version to be the latest version.

When there is a new Compact toolchain release, such as 0.25.0, you will use the same subcommand as above to update to that new version.

You can check if there is a new version available using the check subcommand like this:

compact check

If there is a new version available, you will see something like:

compact: aarch64-darwin -- Update Available -- 0.24.0
compact: Latest version available: 0.25.0.

This is reporting that you are on version 0.24.0 and that 0.25.0 is available.

compact: aarch64-darwin -- Up to date -- 0.24.0

Switching Toolchain Versions

You can also "update" to any other available toolchain, including previous ones. You can list all the versions available with the command:

compact list

The output will look something like this:

compact: available versions

→ 0.24.0 - x86_macos, aarch64_macos, x86_linux
  0.23.0 - aarch64_macos, x86_linux
  0.22.0 - x86_macos, x86_linux

This is showing the different versions, and which platforms they are available for. The arrow indicates the current default version, 0.24.0 in this case. This default is whichever you have currently set as the default (via compact update).

You can pass the flag --installed (or -i) to compact list to see the versions that are actually downloaded locally:

compact list --installed

The output will probably look like this:

compact: installed versions

→ 0.24.0

The update subcommand can be used with a specific version to switch to that version. For example:

$ compact update 0.23.0
compact: aarch64-darwin -- 0.23.0 -- installed
compact: aarch64-darwin -- 0.23.0 -- default.

$ compact list --installed
compact: installed versions

  0.24.0
→ 0.23.0

You can now switch back to the latest version with compact update or compact update 0.24.0. This time, nothing will be downloaded because that version is already installed locally.

Invoking the Compiler

In addition to keeping the toolchain updated, the compact tool will also be the official supported way to invoke all the toolchain tools themselves. For the time being, the only such tool is the compiler, but we will be building out more tools in the future. The compiler can be invoked with the compile subcommand:

compact compile <contract file> <output directory>

This will use the current default version of the toolchain (the one indicated by the arrow in compact list).

You can override the default to use a specific (already installed) version by including the version number after a plus (+) sign like:

compact compile +0.23.0 <contract file> <output directory>

Looking ahead, we plan to remove the compactc executable. Going forward, compact compile will become the standard way to invoke the Compact compiler.

Built-in Help

The compact tool and all of its subcommands have detailed help pages provided by the tools themselves. You can see these in two different ways, either using the help subcommand or by using the --help flag.

For the Compact tool itself, you can invoke compact help or compact --help and you will see the exact same help page. This page shows all the subcommands (compile is currently listed at the bottom of the page). It also shows common command line options.

For a specific subcommand, such as update, you can see detailed help either via compact help update or compact update --help. You can use the help pages to find all the subcommands and their options.

Versions

The developer tools are separately versioned from the toolchain (i.e., compiler) itself. This is because the tools are capable of managing multiple versions of the toolchain.

You can see the version of the developer tools with compact --version. That should currently be 0.1.0. You can also see the version of subcommands like compact update --version. Currently, built-in subcommands (that is, ones implemented by the developer tools, not the toolchain) all have the same version as the developer tools.

You can find the version of the toolchain with compact list -i or compact check (though the latter will make an Internet check to see if there is a new version). You can also find it from the compiler via compact compile --version. This should currently be 0.24.0 if you are on the latest version.

As before, the Compact language itself is versioned separately from the toolchain. You can find this from the compiler via compact compile --language-version.

Keeping the Developer Tools Up to Date

Once they are installed, the developer tools are capable of keeping themselves up to date. You can check for updates with compact self check, and you can update to the latest version of the tool with compact self update.

We have not provided a way to go back to a previous version of the developer tools themselves, because you generally won't need to do that. You don't necessarily have to update the developer tools themselves all the time, either. You will however want to update the developer tools themselves when we make more developer tools available. For example, a future release will include a Compact formatter available via a compact format subcommand. You will need to update the developer tools themselves to get access to the formatter tool. We will always announce such updates in the release notes for both the toolchain and the developer tools.

How it Works

The tool is currently a simple one, but its architecture is flexible and it will eventually support many more different developer tools. If you look at the help pages, you will see that the tools take a --directory command-line flag which tells them where to find the toolchain. By default this will be the directory .compact in your home directory.

If you look in that directory, you will see two subdirectories: bin and versions. The versions subdirectory contains separate subdirectories for each installed version, which contain the toolchain artifacts for that version. The bin subdirectory represents the default version, which is just a symbolic link to one of the installed versions.

The command line tool is capable of checking for updates and downloading and unzipping toolchain artifacts if necessary. Switching between installed versions just changes the bin symbolic link to point to a different installed toolchain. Invoking the toolchain itself just invokes the corresponding default executables in the bin directory, or for a specific version if necessary.

To build on what I learned there, I read two excellent overviews: “A Beginner’s Guide to Ethereum” from Coinbase and “Getting Up to Speed on Ethereum” by Matt. Both helped frame Ethereum not just as a cryptocurrency, but as a foundational platform for Web3 applications. Here’s what stood out and why Ethereum remains vital in a rapidly evolving cryptocurrency ecosystem.

Ethereum in a Nutshell​

Ethereum is a decentralized computing platform. Think of it like a global computer that anyone can access, but no single person or organization controls it. This is possible because Ethereum is powered by a blockchain—a network of nodes around the world that maintain and validate a shared record of activity. What makes Ethereum special is that it doesn’t just store transactions; it can also run applications. These apps are powered by smart contracts, which are programs deployed to the blockchain that execute exactly as written.

The Ethereum network is designed to be open, programmable, and permissionless. That means anyone can build on it, and no one needs approval to use it. This structure has enabled Ethereum to become the foundation for a wide range of decentralized applications (dApps), including financial tools such as lending protocols and stablecoins, as well as NFT marketplaces and decentralized identity systems.

Why Ethereum Matters​

Ethereum matters because it transforms the internet from a read-write platform into a read-write-execute environment. That is, it enables not just the sharing of information, but also the execution of logic—without relying on centralized intermediaries. This shift opens the door to creating systems that are more transparent, resilient, and accessible.

One of Ethereum’s most significant breakthroughs is that it allows developers to write and deploy their own logic onto the network through smart contracts. These contracts can define rules, manage value, and interact with other contracts—all while being trustless and tamper-proof. Once deployed, smart contracts can’t be changed or censored, which means users can interact with them without worrying about backend changes or manipulation.

Ether: The Fuel of the Ethereum Network​

Ether (ETH) is the native currency of Ethereum. While many people think of ETH primarily as a cryptocurrency—something you can buy, sell, or hold—its most important role as the fuel for computation. Every operation on the Ethereum network costs gas, and ETH is what you use to pay for it. This is a crucial aspect of Ethereum’s security and incentive structure, ensuring that resources are utilized responsibly and the network remains resilient to spam.

When you send a transaction, deploy a smart contract, or interact with a dApp, you’re paying for the network to process that request. The more complex the operation, the more gas it consumes. Gas prices fluctuate based on network demand, and users can choose how much to pay to incentivize faster confirmation. This dynamic creates a market for block space, encouraging developers to write more efficient code.

The Power of Smart Contracts​

Smart contracts are at the heart of what makes Ethereum powerful. These are self-executing programs that live on the blockchain and enforce rules automatically. You don’t need to trust a company or a person; you can trust the code. Smart contracts enable a wide range of use cases, including lending platforms like Aave, decentralized exchanges like Uniswap, and even games like Axie Infinity.

Once a smart contract is deployed, it’s public and verifiable. Anyone can inspect the code, interact with it, and build on top of it. This openness fosters a culture of composability—developers can plug into existing contracts, remix them, or build entirely new systems that work together. This is why Ethereum is often referred to as a “LEGO set for financial and digital tools.”

Ethereum Today and Tomorrow​

Ethereum has come a long way since its launch in 2015. It’s no longer just a niche experiment; it’s the most widely used smart contract platform in the world. However, with that growth has come challenges. Network congestion and high gas fees have made it difficult for some users to interact with dApps affordably. To address these issues, Ethereum has undergone significant upgrades, most notably the transition from proof-of-work to proof-of-stake, known as “The Merge.”

Proof-of-stake is a consensus mechanism that allows Ethereum to secure the network using validators who lock up ETH rather than relying on energy-intensive mining. This shift has dramatically reduced Ethereum’s energy usage and paved the way for future scaling efforts, such as sharding and rollups. Rollups are a technique for batching many transactions into a single proof, which can then be submitted to the Ethereum mainnet. This helps scale the network without sacrificing security or decentralization.

The Ethereum ecosystem is also growing through layer 2 networks, which are built on top of Ethereum and handle transactions off-chain while still relying on Ethereum for settlement and security. Projects like Arbitrum, Optimism, and zkSync are working to make Ethereum faster and cheaper for everyday users.

How Ethereum Connects with Midnight​

While Ethereum serves as the foundational smart contract platform for much of Web3, Midnight is designed to complement and extend its capabilities—especially in terms of privacy.

In practical terms, this means that developers who are comfortable with the Ethereum ecosystem —its wallets, development environments, and smart contract models—can interact with Midnight using similar patterns. For example, Midnight supports a Solidity-like programming approach through its Compact smart contract language, which compiles to verifiable circuits that enforce privacy constraints. This allows developers to build private versions of applications, such as voting systems, token transfers, and identity verification, that would typically be public on the Ethereum blockchain.

Ethereum offers programmability and decentralization, but by default, all on-chain transactions are transparent. Midnight fills in the missing privacy layer. You could imagine a workflow where public assets and smart contracts live on Ethereum, but sensitive data or confidential logic is handled by Midnight—bridging the two networks for richer, privacy-preserving applications.

Together, Ethereum and Midnight can be seen as complementary parts of a broader decentralized stack: Ethereum provides openness and composability, while Midnight adds selective disclosure and private computation, enabling developers to build secure and compliant applications in ways that Ethereum alone can’t.

Conclusion​

Ethereum isn’t just a cryptocurrency—it’s a platform for building a new kind of internet. By combining programmable logic with decentralized infrastructure, Ethereum enables applications that are open, transparent, and user-owned. It’s the foundation of decentralized finance (DeFi), non-fungible tokens (NFTs), and numerous experiments in online interaction.

For me, starting with SheFi and reading through these resources helped ground my understanding of what Ethereum is and why it matters. It’s not just about buying coins—it’s about reshaping how we think about trust, ownership, and value in a digital world.

I’ll be back next week as I continue diving into the core building blocks of Web3. If you’re just starting out too, I highly recommend giving Coinbase’s primer and Matt’s breakdown a read.

From ZIP Files to GitHub: Opening the Gates​

Midnight is entering a new phase in our developer journey. Until now, developers had to download ZIP files from our documentation site just to get started. No versioning, no collaboration, no visibility.

That changes today.

The DevRel team is proud to share our first two open source example repositories: example-counter and example-bboard. These projects are more than demos. They’re intentionally scoped, composable references designed to help developers explore what’s possible with Midnight’s privacy-first architecture.

While our broader engineering team continues to open source core protocol components, these repos mark a different kind of milestone: showing others how to build on top of Midnight’s foundation. With versioned code and public visibility, developers can now fork, remix, and build with confidence.

A Simple Contract With a Purpose​

example-counter is a minimal dApp that introduces the fundamentals of building on Midnight. It walks through the full development flow:

• Writing a Compact smart contract
• Running and compiling locally
• Using public state
• Deploying to the Midnight testnet
• Sending transactions

pragma language_version >= 0.16;
import CompactStandardLibrary;

// public state
export ledger round: Counter;

// transition function changing public state
export circuit increment(): [] {
    round.increment(1);
}

It’s designed to build foundational literacy in Compact and Midnight’s dev tooling. It’s a simple but powerful way to learn Compact and become familiar with the development flow on Midnight.

Think of it as a “Hello, World” for privacy-enhancing dApp development.

Enforcing Rules Without Revealing Identity​

example-bboard goes further. It simulates a public bulletin board, where users can post messages, and only the original author can remove their own post.

It’s a small app that teaches a big concept: Midnight enables identity-aware rules without revealing identity.

This repo covers how to:

• Combine public and private state in a Compact contract
• Use zero-knowledge proofs to enforce permissions
• Validate ownership locally without exposing identity
• Design UI flows that respect user privacy by default

It’s especially useful for teams exploring anonymous messaging, private voting, or access control without identity leakage.

What It Means to Build in the Open​

Speaking personally, I’ve spent most of my DevRel career working in open source. But this is the first time I’ve been part of a company transitioning into it.

Open sourcing code isn’t just a technical milestone. It’s a culture shift. Releasing code publicly changes how a team thinks and operates.

It means moving from perfectionism to progress. From private Slack threads to public GitHub Issues. From “we’ll fix it internally” to “anyone can help improve it.”

It’s a commitment to building alongside others, not just for them.

These first example repos mark the beginning of that shift for Midnight. They’re designed to help others learn by doing and to demonstrate that privacy and collaboration can coexist.

Docs Are Up Next​

We’re also preparing to open source our [Midnight Docs repo(https://github.com/midnightntwrk/midnight-docs)].

This is a major step toward transparency, trust, and co-creation. We want the documentation to grow alongside the ecosystem, which means making it easier for contributors to suggest improvements, fix issues, and help shape the developer experience.

What’s Next?​

This is just the start. In the coming months, the DevRel team will:

• Publish more example dApps (and build them from scratch in the open)
• Create reusable components and templates
• Contribute improvements upstream to core tooling
• Document real-world use cases for easier onboarding

We’re building in the open, for those who want to build with us.

Explore the Code​

• example-counter

• example-bboard

Join the Conversation​

We’d love to hear your feedback, contributions, and ideas. Drop into Discord, open an issue, or fork a repo and show us what you’ve built.

As I continue exploring the foundations of Web3, last week I focused on Smart Contracts and Compact—Midnight’s purpose-built smart contract language. Together, these two elements form the foundation for defining and enforcing logic in privacy-preserving applications.

But logic alone isn’t enough in a decentralized system, especially when privacy is a priority. That’s where zero-knowledge proofs (ZKPs) come in.

ZKPs enable the verification of a statement's truth without revealing the underlying justification. They let applications enforce smart contract rules while keeping sensitive data private—an essential capability for building systems that balance trust, utility, and confidentiality.

In this post, I’ll break down what zero-knowledge proofs are, how they work, and how Midnight uses them to support privacy, compliance, and secure dApp development.

What Are Zero-Knowledge Proofs?​

A zero-knowledge proof allows someone (the prover) to prove to another party (the verifier) that a specific statement is true, without revealing any additional information beyond the fact itself.

Think of it like this: instead of handing over your complete ID to prove you're over 18, you could use a ZKP to prove you're above the age threshold, without disclosing your exact birthday, name, or ID number.

This cryptographic technique is built on three foundational properties:

• Completeness: If the statement is true, the prover can convince the verifier that it is true.
• Soundness: If the statement is false, no dishonest prover can convince the verifier that it is true.
• Zero-knowledge: The verifier learns nothing beyond the truth of the statement.

Interactive vs. Non-Interactive Proofs​

Early ZKPs required a back-and-forth exchange between prover and verifier—these are called interactive proofs. But in decentralized systems, interaction isn’t always feasible. That’s where non-interactive proofs come in.

Non-interactive ZKPs let a prover generate a single proof that anyone can verify at any time, with no additional input. Protocols like zk-SNARKs and zk-STARKs make this possible, often using techniques like the Fiat–Shamir heuristic to simulate interaction using cryptographic hashes.

This makes non-interactive ZKPs ideal for blockchains, where proofs need to be public, reusable, and verifiable by anyone.

Types of Zero-Knowledge Proof Systems​

Different ZKP systems come with different tradeoffs in terms of size, speed, and trust requirements:

• Groth16 (zk-SNARK): Very small proofs, fast verification, but requires a trusted setup per circuit.
• Plonk (zk-SNARK): Slightly larger proofs, slower verification, but only needs a one-time universal setup.
• Bulletproofs: No trusted setup, but proof size grows with complexity.
• zk-STARKs: Transparent (no trusted setup), post-quantum secure, but with large proof sizes.

Midnight utilizes a Plonk-derived system called Halo 2, which supports recursive proofs and eliminates trusted setup in specific configurations, making it an ideal choice for privacy-preserving dApps that require both flexibility and scalability.

How Do ZKPs Work?​

The idea behind zero-knowledge proofs might seem almost magical: one party (the prover) can prove to another (the verifier) that a statement is true, without revealing the why. But this is no sleight of hand—it’s grounded in rigorous cryptography and clever use of mathematical structures.

At the heart of a ZKP is a “statement” that the prover wants to validate without revealing the underlying secret. That statement gets encoded into a circuit, which represents the logical rules or constraints that need to be satisfied. The prover then uses a special cryptographic key, known as the proving key, along with the secret input (called the witness), to generate a succinct proof. The verifier can then check this proof using a verifying key, confirming the rules were followed, without ever seeing the private input.

This process makes ZKPs ideal for privacy-preserving smart contracts. In traditional systems, all data must be made public to verify that an action is legitimate. But with ZKPs, we can shift the trust model: rather than inspecting the data itself, the verifier checks a cryptographic proof that the data complies with the rules.

Midnight takes this further by embedding ZKPs directly into the structure and execution of smart contracts. In Midnight, the verification key of a compiled Compact smart contract becomes the identity of that contract on-chain. When users interact with it, they’re not just calling a function—they’re submitting proof that they've complied with the logic defined by that contract, without revealing their inputs.

Here's a high-level flow of how this works:

1. Setup: A circuit is created. A proving key and a verifying key are generated.
2. Proof Generation: The prover uses their secret (a witness) and the proving key to generate a cryptographic proof.
3. Verification: The verifier uses the verifying key and the proof to confirm the statement is true, without learning anything else.

This process ensures that the smart contract logic is executed exactly as intended, without exposing the underlying data.

Midnight’s Approach to ZKPs​

Midnight utilizes zero-knowledge proofs not only for theoretical privacy but also to enable real-world compliance and usability. Let’s walk through a few key elements of how ZKPs show up on the Midnight network:

Confidential Transactions​

Users can transfer assets on Midnight without revealing the sender, receiver, or amount. ZKPs are used to prove that a transaction is valid (i.e., no double spending, balances add up) without revealing specific details. This ensures both privacy and integrity.

Selective Disclosure and Compliance​

Midnight supports “shielded” and “unshielded” data modes. You can keep your transaction data private by default, but also selectively disclose specific information (via a ZKP or viewing key) to a regulator, auditor, or another authorized party.

This enables use cases like “prove I’m a citizen of Country X” or “prove I’m not sanctioned” without revealing your complete identity or wallet history.

For more information about selective disclosure, read my overview here!

Decentralized Identity​

ZKPs are key to proving facts about identity without revealing full credentials. Midnight supports workflows like proving KYC status (“A trusted provider has verified me”) using a proof, not a document.

This allows users to interact with services that require identity checks—such as exchanges or marketplaces—without exposing sensitive personal data.

Scalability via Recursive Proofs​

ZKPs also compress large computations into tiny proofs. That makes them ideal for batching transactions or reducing blockchain bloat. Midnight’s use of recursive proofs allows smart contracts and transactions to scale more efficiently than traditional blockchains.

Real-World Use Cases on Midnight​

Some examples of ZKP-powered applications on Midnight are:

• Voting: Prove you’re eligible to vote and that your vote was counted, without revealing your identity or your vote.
• Whistleblowing: Submit a report anonymously, proving only that you’re authorized (e.g., an employee).
• Private Asset Swaps: Use Midnight’s Zswap to exchange tokens confidentially without revealing terms or participants.
• KYC Onboarding: Prove compliance status to a platform or dApp without exposing documents.
• Tokenized Real-World Assets: Keep ownership private while maintaining auditable transfer records. These use cases show how ZKPs on Midnight turn privacy into a practical feature, not just a theoretical promise. They lay the groundwork for a future where developers can build secure, compliant, and data-protecting applications by default.

Conclusion​

Zero-knowledge proofs bring trust to trustless systems. They make it possible to prove something is true—like compliance with laws, asset ownership, or user eligibility—without revealing any sensitive details.

Midnight makes ZKPs more than theoretical. They’re deeply integrated into its smart contract architecture, transaction model, and developer tooling. Paired with the Compact language (covered in last week’s post), they create a robust foundation for building privacy-first decentralized applications.

If you’re interested in learning more, check out:

• Midnight Developer Academy Module 3
• Zero-Knowledge Proofs in the Midnight Docs

And if you’ve come across excellent ZKP explanations or tutorials, I’d love to hear about them—please share your favorites!

See you next week as I continue to unpack the core ideas that power privacy in Web3!

This article provides a comprehensive guide on connecting to the Midnight blockchain, and you will learn how to listen for new blocks and extract data from these blocks using the Polkadot API and the various methods it provides to connect to Substrate-based blockchains, including Midnight.

See the code in action in this repo, a simple app that watches the Midnight mempool!

Understanding Midnight's Architecture​

Midnight is designed to address the limitations of traditional blockchains regarding data privacy. It does so through:

• Zero-Knowledge Proofs (ZKPs): Enable verification of data without revealing the data itself.
• Dual-Token System: Uses NIGHT (unshielded) for governance and DUST (shielded) for transaction payments.
• Compact Smart Contract Language: A TypeScript-based language facilitating the development of privacy-preserving smart contracts.

These features make Midnight suitable for applications requiring data confidentiality, such as healthcare records, financial transactions, and identity verification.

Connecting to the Midnight Blockchain​

The @polkadot/api library provides a WebSocket provider (WsProvider) to connect to Substrate-based blockchains, which includes Midnight.

Installation​

First, ensure you have the necessary packages installed:

npm install @polkadot/api  

Establishing a Connection​

Use the WsProvider to connect to a Midnight node:

import { ApiPromise, WsProvider } from '@polkadot/api';

// Define the WebSocket endpoint for the Midnight node  
const wsProvider = new WsProvider('wss://rpc.testnet.midnight.network');

// Create the API instance  
const api = await ApiPromise.create({ provider: wsProvider });  

Listening for New Blocks​

Once connected, you can subscribe to new block headers to listen for new blocks:

api.rpc.chain.subscribeNewHeads((lastHeader) => {  
  console.log(`New block #${lastHeader.number} has been added`);  
});  

This function logs the block number each time a new block is added to the chain.

Extracting Data from Blocks​

To extract detailed information from each new block, such as transactions and events, you can use the following approach:

api.rpc.chain.subscribeNewHeads(async (lastHeader) => {  
  const blockHash = await api.rpc.chain.getBlockHash(lastHeader.number);  
  const signedBlock = await api.rpc.chain.getBlock(blockHash);  
  const allEvents = await api.query.system.events.at(blockHash);

  console.log(`nBlock #${lastHeader.number}`);

  signedBlock.block.extrinsics.forEach((extrinsic, index) => {  
    console.log(`nExtrinsic ${index}: ${extrinsic.method.section}.${extrinsic.method.method}`);  
    console.log(`Arguments: ${extrinsic.args.map((arg) => arg.toString()).join(', ')}`);  
  });

  allEvents.forEach(({ event, phase }, index) => {  
    console.log(`nEvent ${index}: ${event.section}.${event.method}`);  
    console.log(`Phase: ${phase.toString()}`);  
    console.log(`Data: ${event.data.toString()}`);  
  });  
});  

This script subscribes to new block headers, retrieves the full block and its associated events, and logs detailed information about each extrinsic (transaction) and event.

What is an extrinsic?​

In the context of Substrate-based blockchains like Midnight, an extrinsic refers to any piece of information originating from outside the blockchain's runtime that is submitted to the network for inclusion in a block. Extrinsics are the primary means by which users and external entities interact with the blockchain, enabling state changes and other operations.

There are three main types of extrinsics:

• Signed Extrinsics: These are transactions submitted by users that include a digital signature. They often involve actions like transferring tokens or interacting with smart contracts. The signature ensures authenticity and allows the network to charge transaction fees.
• Unsigned Extrinsics: These are submitted without a signature and are typically used for operations that don't require user authentication. They might be subject to custom validation logic to prevent misuse.
• Inherent Extrinsics: Generated by the blockchain itself, these are used for system-level operations, such as setting the timestamp for a new block. They are not propagated through the network like other extrinsics but are included by block producers during block creation.

Understanding extrinsics is crucial for developers working with Substrate-based blockchains, as they represent the fundamental mechanism for enacting changes and interacting with the network's state.

Conclusion​

By utilizing the WsProvider from the @polkadot/api library, developers can effectively connect to the Midnight blockchain, monitor new blocks in real-time, and extract pertinent data for their applications. This approach provides a robust foundation for building privacy-focused decentralized applications on the Midnight network.

For more information and detailed documentation, visit the Midnight Developer Hub.

In part 1, we used the Bulletin Board tutorial contract as an example. We compiled it with the Compact compiler and started looking at the files generated by the compiler. We used Compact toolchain version 0.24.0. Recall the caveat from part 1 that the generated code is an implementation detail of the platform. We freely change it, so it can be different when different versions of the compiler are used.

Circuits​

We looked at the bulletin board contract’s post circuit. The compiler generated a TypeScript declaration file that includes a declaration for the circuit:

post(context: __compactRuntime.CircuitContext<T>, newMessage_0: string): __compactRuntime.CircuitResults<T, []>;

Recall that the types CircuitContext and CircuitResults came from the Compact runtime used by the compiler.

In the file index.cjs the compiler has generated a JavaScript implementation of this circuit. You will find this in the contract subdirectory of the compiler output directory you gave on the compact command line when compiling the contract’s Compact source code.

The implementation is installed as a property on the circuits object of the contract in class Contract’s constructor. The entirety of the code is here (we will drill down into this in the rest of this section):

this.circuits = {
  post: (...args_1) => {
    if (args_1.length !== 2)
      throw new __compactRuntime.CompactError(`post: expected 2 arguments (as invoked from Typescript), received ${args_1.length}`);
    const contextOrig_0 = args_1[0];
    const newMessage_0 = args_1[1];
    if (!(typeof(contextOrig_0) === 'object' && contextOrig_0.originalState != undefined && contextOrig_0.transactionContext != undefined))
      __compactRuntime.type_error('post',
                                  'argument 1 (as invoked from Typescript)',
                                  'bboard.compact line 26 char 1',
                                  'CircuitContext',
                                  contextOrig_0)
    const context = { ...contextOrig_0 };
    const partialProofData = {
      input: {
        value: _descriptor_4.toValue(newMessage_0),
        alignment: _descriptor_4.alignment()
      },
      output: undefined,
      publicTranscript: [],
      privateTranscriptOutputs: []
    };
    const result_0 = this.#_post_0(context, partialProofData, newMessage_0);
    partialProofData.output = { value: [], alignment: [] };
    return { result: result_0, context: context, proofData: partialProofData };
  },

Runtime Type Checks​

The first part of this implementation is so-called “boilerplate” code that is generated by the compiler for every circuit. Every circuit has essentially the same code, differing only slightly depending on the number and names of the arguments, file names, and source code positions. Let’s focus on that code first:

if (args_1.length !== 2)
  throw new __compactRuntime.CompactError(`post: expected 2 arguments (as invoked from Typescript), received ${args_1.length}`);
const contextOrig_0 = args_1[0];
const newMessage_0 = args_1[1];
if (!(typeof(contextOrig_0) === 'object' && contextOrig_0.originalState != undefined && contextOrig_0.transactionContext != undefined))
  __compactRuntime.type_error('post',
                              'argument 1 (as invoked from Typescript)',
                              'bboard.compact line 26 char 1',
                              'CircuitContext',
                              contextOrig_0)
const context = { ...contextOrig_0 };

There are some runtime type checks here. First, we check that the actual number of arguments passed matches the expected number. In this case, that’s two (the second one is the circuit’s parameter newMessage and the first one is the CircuitContext parameter inserted by the compiler). If not, we’ll throw an exception.

This is one way that Compact differs from TypeScript. The JavaScript code produced by the TypeScript compiler does not check argument counts or types at run time because it assumes that the calling code has also passed the TypeScript type checker. Because the correctness of your contracts will depend on it, we do not assume that. Instead, the generated JavaScript code will perform the appropriate checks at run time.

A const binding is used to give the first argument a name based on contextOrig (always) and the second argument is named based on whatever name we used in the Compact source code. The suffixes like _0 added on variable names is the way that the compiler ensures that it always generates unique names. Then we have some runtime type checks that the first argument actually satisfies the interface for CircuitContext defined in the Compact runtime.

Finally, we copy the original CircuitContext and name it context. We do this so that we can mutate the copy without changing the original one that was passed to us.

Proof Data​

The big-picture view of a post transaction is that it runs the JavaScript implementation of the circuit, with full access to the private state provided by its witnesses. Then we ask the proof server to generate a zero-knowledge (ZK) proof that the circuit ran as expected. Specifically, we prove that we know the private data required to produce the observed on-chain behavior—without revealing that private data.

In order to do that, we have to collect some information about running the circuit in the so-called “proof data”. We next initialize that data:

const partialProofData = {
  input: {
    value: _descriptor_4.toValue(newMessage_0),
    alignment: _descriptor_4.alignment()
  },
  output: undefined,
  publicTranscript: [],
  privateTranscriptOutputs: []
};

This is a JavaScript value that satisfies the TypeScript interface ProofData from the Compact runtime. To understand this, we need to look inside of the definition. That definition (from the version of the Compact runtime used by the Compact compiler version 0.24.0) is:

interface ProofData {
  input: AlignedValue;
  output: AlignedValue;
  privateTranscriptOutputs: AlignedValue[];
  publicTranscript: Op<AlignedValue>[];
}

This is called partialProofData because it will not necessarily contain all the proof data that we need. When we run the JavaScript code for the circuit off chain, some conditional branches will be skipped. In these cases, the proof will require 'dummy' data to fill in for branches that were not taken. We’ll explore that in more detail later in the series.

The initial value is kind of like the boilerplate we saw before. The properties input, output, and publicTranscript have default initial values. The initial value of input depends on the number and types of the parameters to the circuit in Compact:

From the TypeScript declaration of ProofData, we can see that input has type AlignedValue. This is the type alias AlignedValue from the Compact runtime. And from the TypeScript declaration for that we can see that it has a pair of properties, alignment and value.

Descriptors​

To fully understand this, let’s take a look at the Compact runtime TypeScript declaration of AlignedValue:

type AlignedValue = {
  alignment: Alignment;
  value: Value;
};

We’ll gloss over Alignment, but it’s instructive to see what Value is:

type Value = Uint8Array[];

So an aligned value is an alignment tag of some kind and a value which is an array of Uint8Arrays. This is the ledger’s encoding of Compact values in the on-chain runtime. That’s a different encoding from the JavaScript encoding of the same value.

We have two different representations for the same values. One is native JavaScript objects. The other is a binary encoding, used in the on-chain runtime. To convert between these two representations, we use so-called “descriptors”. They are the JavaScript representation of Compact types. More specifically, they are objects implementing the CompactType interface. They have three methods: toValue to convert from a JavaScript value to an on-chain value, fromValue to convert from an on-chain value to a JavaScript value, and alignment to return the alignment of the on-chain value.

The code for the ProofData’s input (representing the post circuit’s newMessage argument) was:

input: {
  value: _descriptor_4.toValue(newMessage_0),
  alignment: _descriptor_4.alignment()
},

The compiler generates top-level const bindings in JavaScript for a number of descriptors that it has used in the generated JavaScript code. If we look at _descriptor_4 in index.cjs we see:

const _descriptor_4 = new __compactRuntime.CompactTypeOpaqueString();

It’s an instance of a descriptor for a Compact value of type Opaque<"string">. The Compact runtime defines descriptor classes for all the Compact types, such as CompactTypeOpaqueString.

The JavaScript representation of the Compact type Opaque<"string"> is as a JavaScript string and the ledger representation is as a (tagged) single-element array consisting of the JavaScript string’s UTF-8 encoding. The proof data we will build up while executing the circuit contains ledger representations of values, so we use the descriptor’s toValue method to convert the newMessage parameter to that representation.

Wrapping it Up​

Finally, we have a last little bit of code:

const result_0 = this.#_post_0(context, partialProofData, newMessage_0);
partialProofData.output = { value: [], alignment: [] };
return { result: result_0, context: context, proofData: partialProofData };

This calls a method on the contract named #_post_0, which contains the actual implementation of the post circuit. What we’ve been looking at (the post method) is a mostly boilerplate wrapper around this implementation. The implementation method takes the context and passes along the arguments, along with the proof data object we’ve constructed for it.

Then after it returns, we will set the output property of the proof data. The way that’s set depends on the return type of the Compact circuit. In this case it was the Compact type [], so that’s relatively uninteresting. If you take a look at the takeDown circuit in the same contract, you will see the slightly more interesting:

partialProofData.output = { value: _descriptor_4.toValue(result_0), alignment: _descriptor_4.alignment() };

Remember that _descriptor_4 was the one for the Compact type Opaque<"string">, and the proof data has ledger values. The circuit implementation in JavaScript will return a JavaScript value, so we need to encode it into the ledger’s representation using toValue and alignment.

And finally, we return the result of the circuit invocation. Recall that this was a CircuitResults<T, []> (where T is the contract’s private state type). That interface is in the Compact runtime and it looks like:

interface CircuitResults<T, U> {
  context: CircuitContext<T>;
  proofData: ProofData;
  result: U;
}

We will look more closely into the actual circuit implementation #_post_0 in the next article in this series.

What are Wrappers For?​

Why do we wrap the implementation in this way? There are a couple of reasons.

First, the mostly boilerplate code we have been looking at is used when we call the circuit from JavaScript code in our DApp. So it needs to have the extra runtime checks that we see for safety. But when we call the circuit from another Compact circuit, we do not need these type checks. The Compact type system guarantees that we don’t need extra runtime checks, so we can directly call the implementation function (such as #_post_0).

And second, when we call a Compact circuit from another one, that is considered part of the same transaction that we are constructing. So in that case, we don’t want to construct a fresh ProofData object to pass in, and we don’t want to box up the results in a CircuitResults object. We only need to do that at the outermost circuit call, coming from the DApp’s JavaScript code.

Witnesses​

Let’s take a quick look at the implementation of witnesses. Our contract has one, and we expect it to be passed in when we construct the contract. The constructor for class Contract has some runtime type checking code for that:

constructor(...args_0) {
  if (args_0.length !== 1)
    throw new __compactRuntime.CompactError(`Contract constructor: expected 1 argument, received ${args_0.length}`);
  const witnesses_0 = args_0[0];
  if (typeof(witnesses_0) !== 'object')
    throw new __compactRuntime.CompactError('first (witnesses) argument to Contract constructor is not an object');
  if (typeof(witnesses_0.localSecretKey) !== 'function')
    throw new __compactRuntime.CompactError('first (witnesses) argument to Contract constructor does not contain a function-valued field named localSecretKey');
  this.witnesses = witnesses_0;

Then, probably more interesting, the witnesses are also wrapped. The contract has a method for each witness, like:

#_localSecretKey_0(context, partialProofData) {
  const witnessContext_0 = __compactRuntime.witnessContext(ledger(context.transactionContext.state), context.currentPrivateState, context.transactionContext.address);
  const [nextPrivateState_0, result_0] = this.witnesses.localSecretKey(witnessContext_0);
  context.currentPrivateState = nextPrivateState_0;
  if (!(result_0.buffer instanceof ArrayBuffer && result_0.BYTES_PER_ELEMENT === 1 && result_0.length === 32))
    __compactRuntime.type_error('localSecretKey',
                                'return value',
                                'bboard.compact line 24 char 1',
                                'Bytes<32>',
                                result_0)
  partialProofData.privateTranscriptOutputs.push({
    value: _descriptor_2.toValue(result_0),
    alignment: _descriptor_2.alignment()
  });
  return result_0;
}

The circuit wrapper post was used when we called the circuit from JavaScript code, and bypassed (by directly calling the implementation #_post_0) when we called it from Compact code. For witnesses, the situation is reversed. You can call your witnesses (like witnesses.localSecretKey) all you want from JavaScript code and we don’t care and won’t even observe it. But if you call them from a Compact circuit, we will need to know about it, so we’ll call a wrapper (like localSecretKey_0).

Your witness implementation expects to have a WitnessContext argument passed to it, so here we’ll construct one to pass in. It contains the ledger, current private state, and the contract’s address. We get the JavaScript representation of the public ledger state using the compiler-generated ledger function that we looked at in part 1 of this series.

Then we actually invoke your witness implementation, getting the result and a new private state. We mutate the context to update the private state (remember, we copied the original context before invoking a circuit implementation so it was safe to mutate the copied context).

Next, we have runtime type checks after the witness returns. This is for the same reason that we check arguments coming in to circuits from JavaScript: we don’t control the witness implementation and we need to make sure that the return value is as expected for the circuit. Compact’s type safety depends on these runtime checks.

Finally, we record the witness’s return value in the proof data's private transcript that we are building while running the outermost Compact circuit call. This is private data and so for the ZK proof we construct the proof server will need to know it (so the proof server can prove that it knows the private data).

In the next article in this series, "Compact Deep Dive Part 3: The On-Chain Runtime", we will take a closer look at the actual implementation of the post circuit from the bulletin board contract and see how it uses the on-chain runtime.

Smart contracts aren’t new to blockchain, but Midnight’s approach is unique. Instead of executing code directly on-chain, Midnight uses smart contracts to define rules that are enforced off-chain through zero-knowledge proofs. At the center of this system is Compact—a purpose-built language designed to make writing these privacy-preserving contracts both secure and practical.

To better understand how this works in practice, I also worked through Module 2 of the Midnight Developer Academy, which covers key concepts such as contract structure, circuit types, and the relationship between the contract and the external logic that executes it.

In this post, I’ll break down what makes smart contracts on Midnight different, how Compact is structured, and how the two work together to enable provable logic without exposing sensitive data.

What Is a Smart Contract on Midnight?​

At a high level, a smart contract is an autonomous program stored on the blockchain. It defines rules for interaction, checks that those rules are met, and records results—all without needing a trusted third party to enforce them.

But Midnight isn’t just any blockchain. It’s a privacy-first platform built with compliance in mind, and that means its smart contracts need to do more than just run logic. They need to protect private data, enable selective disclosure, and uphold security and trust even in adversarial environments.

That’s where Compact comes in—a custom domain-specific language explicitly designed to write smart contracts on Midnight.

Instead of executing logic directly on-chain like many traditional smart contracts, Compact contracts define the logic to be proven, not the execution environment itself. The contract encodes the rules that must be followed, which are then used as the foundation for a zero-knowledge proof. The actual execution—like processing a transaction, generating a credential, or submitting a vote—happens externally, often in a DApp, backend service, or API.

That external system runs the necessary logic and proves it followed the contract’s rules by generating a cryptographic proof. The blockchain doesn’t need to know the details—it just verifies that the proof is valid. This separation is what makes Midnight’s model both scalable and privacy-preserving.

In other words: the contract sets the rules, your app runs the logic, and the blockchain verifies the outcome, without ever seeing the sensitive inputs.

What Is Compact?​

Compact is a statically typed, privacy-focused smart contract language tailored to the unique goals of the Midnight network. If you've worked with JavaScript or TypeScript before, you'll find Compact refreshingly approachable. It’s a domain-specific language (DSL) designed to define zero-knowledge proof logic using statically typed circuits that map to off-chain computations. But don’t let the simple syntax fool you—Compact is engineered for privacy-preserving computation using zero-knowledge proofs (ZKPs) under the hood. (For a more technical deep dive into compact, check out part 1 of Kevin Millikin's Compact Deep Dive here!)

A Compact contract is made up of three core components:

• Ledger: The public, on-chain state of the contract.
• Circuits: Off-chain logic that can manipulate data, produce proofs, and interact with the ledger.
• Witnesses: Privately held data, only known to the entity executing the contract.

Compact also supports explicit disclosure, meaning developers can define exactly what data gets revealed (and to whom). This provides fine-grained control over what is visible on-chain and what remains private, essential for use cases such as private asset transfers, age-gated access, or confidential voting.

Circuits and Privacy​

One of the most essential takeaways from Module 2 of the Midnight Developer Academy is how circuits work. In Compact, circuits are the functions that users or systems can call to trigger actions. But unlike Web2 APIs or EVM contract functions, these circuits don’t execute logic directly on the blockchain. Instead, they run off-chain and generate zero-knowledge proofs that the logic was followed.

In practice, that means:

• The contract logic is public.
• The data used during execution is private.
• The outcome of the logic (e.g., “the rules were followed”) is publicly verifiable using a proof.

This is where Midnight’s model shows its strength—users can prove they followed the rules without revealing the exact data that triggered the result. Think “I proved I’m eligible to vote” without revealing who I am or what I voted for.

From Theory to Practice​

In traditional smart contract platforms, everything you do is public by default: data, logic, inputs, outputs. That’s useful for transparency, but it's not always practical, especially for sensitive use cases like health data, financial records, or identity verification.

Midnight flips that default. Privacy is built in, and developers opt into disclosure only when it’s needed.

Some examples of what you might build with Compact on Midnight:

• A voting system where only the outcome is public.
• An access control system that verifies user attributes without revealing identities.
• A token transfer app that hides amounts or senders while still allowing public verification.

Conclusion​

Smart contracts are the foundation of decentralized applications—but at Midnight, they’re built for a privacy-first future. Instead of executing every piece of logic on-chain, Midnight separates the contract's logic from its execution. With Compact, developers define the rules of a zero-knowledge proof system, enabling applications to prove facts without exposing sensitive data. It’s a practical shift toward secure, scalable, and user-protective Web3 design.

At Midnight, this isn’t just a theoretical improvement—it’s core to how the platform operates. Compact smart contracts let developers write verifiable, auditable logic while keeping inputs and execution off-chain. Combined with ZKPs and shielded transactions, they create an infrastructure that supports real-world use cases without compromising on privacy or decentralization.

If you're learning how to build smart contracts in Web3—or just curious how these pieces fit together—I highly recommend diving into Module 2 of the Midnight Developer Academy and reviewing the Compact Language Reference. These resources break down the concepts step by step and show how Midnight’s architecture turns advanced cryptography into practical developer tools.

I’ll be back next week with more insights as I continue to unpack the pieces that make privacy-first systems work in the decentralized world.

These insights reflect the current architecture, but since they describe low-level mechanics, they may change as the platform evolves.

One caveat to keep in mind is that almost everything here should be considered an implementation detail. That means that the details are not stable, and they can and will change as we see fit.

Overview of the Bulletin Board Contract​

We'll use our old favorite, Bulletin Board as an example. We're compiling this with Compact toolchain version 0.24.0. The Compact language is a moving target as we introduce and change features, so this code may not compile with any Compact toolchain version other than 0.24.0.

pragma language_version 0.16;

import CompactStandardLibrary;

export enum State {
  VACANT,
  OCCUPIED
}

export ledger state: State;

export ledger message: Maybe<Opaque<"string">>;

export ledger instance: Counter;

export ledger poster: Bytes<32>;

constructor() {
  state = State.VACANT;
  message = none<Opaque<"string">>();
  instance.increment(1);
}

witness localSecretKey(): Bytes<32>;

export circuit post(newMessage: Opaque<"string">): [] {
  assert(state == State.VACANT, "Attempted to post to an occupied board");
  poster = disclose(publicKey(localSecretKey(), instance as Field as Bytes<32>));
  message = disclose(some<Opaque<"string">>(newMessage));
  state = State.OCCUPIED;
}

export circuit takeDown(): Opaque<"string"> {
  assert(state == State.OCCUPIED, "Attempted to take down post from an empty board");
  assert(poster == publicKey(localSecretKey(), instance as Field as Bytes<32>), "Attempted to take down post, but not the current poster");
  const formerMsg = message.value;
  state = State.VACANT;
  instance.increment(1);
  message = none<Opaque<"string">>();
  return formerMsg;
}

export circuit publicKey(sk: Bytes<32>, instance: Bytes<32>): Bytes<32> {
  return persistentHash<Vector<3, Bytes<32>>>([pad(32, "bboard:pk:"), instance, sk]);
}

We’ll focus on the post circuit. First, let’s refresh your memory about the basics of the contract. It declares a Compact enum type for the bulletin board’s state, and it declares some ledger fields. Three of them are mutable ledger cells and one of them is a Counter:

export enum State {
  VACANT,
  OCCUPIED
}

export ledger state: State;

export ledger message: Maybe<Opaque<"string">>;

export ledger instance: Counter;

export ledger poster: Bytes<32>;

There is a witness that has access to private state. This is a foreign function implemented in JavaScript or TypeScript. It looks up the user’s secret key somehow and returns it. The post circuit makes sure that the bulletin board is in the VACANT state and, if so, uses the witness to get the secret key and updates the three cells in the ledger:

witness localSecretKey(): Bytes<32>;

export circuit post(newMessage: Opaque<"string">): [] {
  assert(state == State.VACANT, "Attempted to post to an occupied board");
  poster = disclose(publicKey(localSecretKey(), instance as Field as Bytes<32>));
  message = disclose(some<Opaque<"string">>(newMessage));
  state = State.OCCUPIED;
}

There is also a helper circuit called publicKey, which is used by both the post and takeDown circuits.
Declaring publicKey as exported has two effects:

• It makes the circuit callable from TypeScript or JavaScript.
• It makes it a contract entry point, allowing publicKey transactions to be submitted to the Midnight blockchain.

export circuit publicKey(sk: Bytes<32>, instance: Bytes<32>): Bytes<32> {
  return persistentHash<Vector<3, Bytes<32>>>([pad(32, "bboard:pk:"), instance, sk]);
}

A Look Under the Hood​

Presuming compact is in your path, you can compile the Bulletin Board contract directly. If the code is in a file named bboard.compact, change to the directory where that file is located. Then run compact compile, passing the source file and an output directory:

$ compact compile bboard.compact bboard-out
Compact version: 0.24.0
Compiling 2 circuits:
  circuit "post" (k=14, rows=10070)  
  circuit "takeDown" (k=14, rows=10087)  
Overall progress [====================] 2/2

Let’s take a look at what the compiler has generated:

$ ls bboard-out
compiler        contract        keys            zkir

There are four subdirectories. compiler has some metadata about the contract that will be used by composable contracts, which we can just ignore for now. keys and zkir are related to the ZK proofs which we will talk about in a later article. The compiler has translated the contract code into a JavaScript implementation, which is in the contract subdirectory. We’ll focus on that first.

$ ls bboard-out/contract
index.cjs       index.cjs.map   index.d.cts

There are three files here. index.cjs is the JavaScript implementation of the contract. (It is JavaScript source code, the .cjs extension means that it uses the CommonJS module system.) There is a source map file index.cjs.map that can be used for debugging. It connects the JavaScript implementation in index.cjs back to the original Compact source code that was in bboard.compact. Finally, there is a TypeScript declaration file index.d.cts for the JavaScript implementation. This allows the JavaScript code in index.cjs to be called from TypeScript (and importantly, type checked by the TypeScript compiler).

We have chosen this strategy (a JavaScript implementation with a TypeScript declaration file, instead of a pure TypeScript implementation) for a couple of reasons. First, it lets us generate runtime checks in the JavaScript code for things that wouldn’t be checked by TypeScript’s type system. And second, we can generate a source map for debugging that maps the implementation back to the Compact source code. The source map you would get from the TypeScript compiler would only connect the TypeScript compiler generated JavaScript code back to Compact compiler generated TypeScript, not all the way back to the original Compact source code.

TypeScript Declaration​

Now, let’s take a first look at the structure of the contract’s implementation by looking inside the TypeScript declaration file index.d.cts. We will walk through this file, though not necessarily in order. Before reading further, we encourage you to compile the code to generate this file and take a look at it yourself.

Remember, this was generated with Compact toolchain version 0.24.0. If you try the same thing with a different version, you might see different implementation details.

The Compact Runtime​

The very first thing you will see is:

import type * as __compactRuntime from '@midnight-ntwrk/compact-runtime';

This imports the Node.js package @midnight-ntwrk/compact-runtime which is an API used by the Compact compiler’s generated JavaScript code. Separating it out like this decouples the runtime from the compiler implementation, and it means that the generated JavaScript code can be smaller. We’ll see later that the Compact runtime is quite complex (it re-exports a large part of the on-chain runtime which is implemented in Rust and compiled to WebAssembly).

You can even import this package in your DApp to have your own access to Compact runtime types and functions if necessary. The API documentation for the Compact runtime is available in the Midnight documentation.

Compact enum Types​

The bulletin board contract declared a Compact enum type for the bulletin board’s state (vacant or occupied). This type was exported (via the export keyword) which makes it available to a DApp’s TypeScript or JavaScript implementation, so there is a declaration in the TypeScript declaration file:

export enum State { VACANT = 0, OCCUPIED = 1 }

If this enum type was not exported in Compact, we would not see this declaration. Then, whenever this type appeared in the contract’s API (like in a circuit parameter or in the ledger) we would instead see the the underlying TypeScript representation type number. (Try it and see! Remove the export keyword for the enum in the Compact contract. Note that if you merely want to look at the generated TypeScript or JavaScript contract code you can skip ZK key generation by passing the command-line flag --skip-zk to the Compact compiler. This will run much faster.)

The Compact Ledger​

In Compact, the contract’s public state is established by ledger declarations. The compiler collects all of these and exposes them to the DApp in the form of a ledger type:

export type Ledger = {
  readonly state: State;
  readonly message: { is_some: boolean, value: string };
  readonly instance: bigint;
  readonly poster: Uint8Array;
}

It has read-only properties for all the ledger fields. They are read-only in TypeScript, because updating the ledger actually requires a transaction to be submitted to the chain. A DApp, however, can freely read them from (a snapshot of) the public ledger state.

We mentioned before that State appears in this API because we exported the Compact enum type State. Notice that the Compact standard library type Maybe does not appear in this API. Instead, the ledger field message has the underlying TypeScript type. That’s because we didn’t export the standard library’s Maybe type. We could do that with export { Maybe } at the top level of our Compact contract, and then we would instead see:

export type Maybe<a> = { is_some: boolean; value: a };

export type Ledger = {
  readonly state: State;
  readonly message: Maybe<string>;
  readonly instance: bigint;
  readonly poster: Uint8Array;
}

There is also a declaration of a function that gives us (a read-only snapshot of) the public ledger state, returning a TypeScript value of type Ledger as declared above:

export declare function ledger(state: __compactRuntime.StateValue): Ledger;

This function takes a value of the Compact runtime’s type StateValue. We will see in Part 2 of this series how this function is used to pass a Ledger to witnesses.

Compact Circuits​

Our contract had three exported circuits. By exporting them, they are made available to be called by the DApp’s TypeScript or JavaScript code, and they form the contract’s entry points. We can see declarations for them in the TypeScript declaration file, in two different places:

export type ImpureCircuits<T> = {
  post(context: __compactRuntime.CircuitContext<T>, newMessage_0: string): __compactRuntime.CircuitResults<T, []>;
  takeDown(context: __compactRuntime.CircuitContext<T>): __compactRuntime.CircuitResults<T, string>;
}

export type PureCircuits = {
  publicKey(sk_0: Uint8Array, instance_0: Uint8Array): Uint8Array;
}

export type Circuits<T> = {
  post(context: __compactRuntime.CircuitContext<T>, newMessage_0: string): __compactRuntime.CircuitResults<T, []>;
  takeDown(context: __compactRuntime.CircuitContext<T>): __compactRuntime.CircuitResults<T, string>;
  publicKey(context: __compactRuntime.CircuitContext<T>,
            sk_0: Uint8Array,
            instance_0: Uint8Array): __compactRuntime.CircuitResults<T, Uint8Array>;
}

The post and takeDown circuits are impure. In Compact, this basically means that they access (even if only by reading) the public state and/or they invoke witnesses. They are declared in the type ImpureCircuits<T>. The generic type parameter T here is the type of the contract's private state. The Compact compiler doesn't know what that type is (nor does it need to); it's up to the DApp developer to fill that in.

Recall the Compact signature of the post circuit was circuit post(new_message: Opaque<"string">): []. We can see that the TypeScript API for this circuit is predictably derived from the Compact signature, with a few differences.

First, the circuit takes an extra first argument of type CircuitContext<T>. This is an interface declared in the Compact runtime. It contains an encapsulation of the contract's on-chain and private state, some separate Zswap state, and a representation of what the on-chain context would be if the circuit were actually executing on chain (though note, this JavaScript code is not what's executed on chain).

Second, we can see that the Compact type Opaque<"string"> is represented by the TypeScript type string. One goal of Compact is that the TypeScript representation of Compact types is always predictable.

And third, we can see that the return type (in Compact it was []) is actually CircuitResults<T, []>. This is another interface declared in the Compact runtime. It has the actual return value with TypeScript type [], as well as some proof data required to construct the ZK proof and a new CircuitContext<T> representing the public and private state after running the circuit.

We won’t focus on takeDown here, but you can see that its signature is similarly and predictably derived from the signature of the circuit in Compact.

The helper circuit publicKey is pure. This means that it does not access the public state or invoke witnesses (i.e., it's not impure). It is declared in the type PureCircuits. Pure circuits are ones that can run without an instance of the contract. Specifically, they do not need access to the ledger state and they do not have access to private state. You can see that here, because the extra first CircuitContext argument is missing, and the return value is a bare TypeScript type rather than a CircuitResult. The type PureCircuits is not generic, there is no type parameter T needed to represent the type of the private state.

Finally, these declarations are repeated in the type Circuits<T>. The declarations of post and takeDown are exactly the same as before, but the declaration of publicKey has the signature of an impure circuit. This is so that the DApp can make a publicKey transaction, without having to worry about the details of whether it's pure or not.

There are implementations of these circuits in the compiler-generated JavaScript code for the contract, which we will look at in the next article in this series.

Compact Witnesses​

We had a single witness declaration in our contract, which is also reflected in the contract’s TypeScript API:

export type Witnesses<T> = {
  localSecretKey(context: __compactRuntime.WitnessContext<Ledger, T>): [T, Uint8Array];
}

The witness’s signature is also predictably derived from the Compact witness declaration. It has an extra first argument of type WitnessContext<Ledger, T>. This interface is declared in the Compact runtime. It contains a snapshot of the public ledger state, the contract’s private state of type T, and the contract’s address. The witness returns a tuple (a two-element TypeScript array) consisting of a new private state of type T and the Compact return value. The Compact type Bytes<32> is represented by the underlying TypeScript type Uint8Array.

The DApp implementation is responsible for providing a witness with this signature when constructing the contract.

The Contract Type​

Finally, there is a declaration of the contract type:

export declare class Contract<T, W extends Witnesses<T> = Witnesses<T>> {
  witnesses: W;
  circuits: Circuits<T>;
  impureCircuits: ImpureCircuits<T>;
  constructor(witnesses: W);
  initialState(context: __compactRuntime.ConstructorContext<T>): __compactRuntime.ConstructorResult<T>;
}

export declare const pureCircuits: PureCircuits;

It is parameterized over the private state type and the witness type, and it has witnesses, circuits, impure circuits, a constructor, and an initial state all using the type declarations seen above. The pure circuits are a top-level TypeScript value (rather than a contract property), representing the fact that they do not need an instance of the contract.

The contract itself is implemented by the compiler-generated JavaScript code in index.cjs. In the next article in this series, "Compact Deep Dive – Part 2: Circuits and Witnesses", we’ll begin examining how circuits and witnesses are implemented in the generated code.

Selective disclosure is more than just a technical feature—it’s the working expression of a broader idea known as rational privacy. It allows individuals to prove or reveal only what’s necessary in a given interaction, keeping everything else private. In an ecosystem where trust must be earned without a central authority, this ability to protect personal data while still meeting legal or operational requirements is critical.

This post examines how selective disclosure operates, its benefits, and how platforms like Midnight are implementing it through privacy-first smart contracts.

What Is Selective Disclosure?​

In the Web3 world, privacy doesn’t mean keeping everything secret—it means sharing only what’s necessary. Selective disclosure is a privacy-preserving technique that enables individuals to disclose specific information for a given interaction while keeping all other personal data confidential.

This approach is a practical expression of a broader concept known as rational privacy. Rational privacy is the idea that privacy shouldn’t be absolute or all-or-nothing—it should be contextual. It recognizes that in many real-world scenarios, users want to share some data to gain access to services or meet legal obligations, but they shouldn't be forced to give up all privacy and security in the process. It’s about striking a balance between personal control, usability, and regulatory compliance.

Selective disclosure is the technical implementation of rational privacy. It gives users and developers the cryptographic tools to protect sensitive information by default, while still enabling the right level of transparency when it’s required. This makes it especially relevant for public blockchain networks, where data is immutable and visible by design.

A typical example of selective disclosure in action is the use of Verifiable Credentials (VCs). VCs allow users to prove attributes—like age, residency, or educational background—without revealing the entire credential. This aligns with the principles of data minimization and privacy by design, ensuring individuals remain in control of their information.

This balance between usability and privacy is what makes selective disclosure so powerful—and so relevant for real-world blockchain applications. But beyond the technical implementation, it's worth asking: what are the practical benefits of using selective disclosure in the first place?

Benefits of Selective Disclosure​

When integrated thoughtfully, selective disclosure brings both technical and human-centric advantages to decentralized systems. It enables individuals and organizations to meet privacy expectations and compliance standards without sacrificing functionality. Implementing selective disclosure offers several advantages:

• Enhanced Privacy: Selective disclosure enables users to share only the data necessary for a specific interaction, rather than disclosing full credentials or identity documents. This dramatically reduces the surface area for privacy breaches and surveillance. Whether you’re accessing a service, submitting a form, or interacting with a smart contract, your unnecessary personal data stays out of view.
• Data Minimization and Compliance: This principle, core to privacy laws such as GDPR and HIPAA, requires that only the minimum amount of personal data necessary for a task is collected or processed. Selective disclosure naturally enforces this, making it easier for developers and organizations to design privacy-respecting systems by default.
• User Empowerment and Control: In traditional systems, users often hand over their entire dataset for one small verification (e.g., uploading an entire ID just to prove their age). Selective disclosure flips that dynamic, giving users the power to control what they share, when, and with whom. This supports a more user-centric data model, where individuals become the custodians of their credentials.
• Reduced Risk of Data Misuse: The less information that’s exposed, the lower the risk of that data being lost, stolen, or misused. Selective disclosure reduces the need for centralized data storage (e.g., big ID databases), limiting attack vectors for fraud and identity theft. Even if a transaction or credential presentation is intercepted, only the minimum disclosed attribute is visible, keeping the rest safe.
• Lower Liability and Operational Overhead for Businesses: Many organizations would prefer not to collect or store sensitive user data due to the associated risks, regulatory requirements, and administrative burdens. Selective disclosure offers a path forward, enabling users to demonstrate eligibility or compliance without requiring businesses to retain or manage that data. This can reduce costs, simplify operations, and improve overall data security posture.

While selective disclosure introduces a powerful model for user-centric privacy, it also comes with its own set of technical and usability challenges. Understanding these limitations is essential for builders and organizations aiming to adopt it responsibly.

Potential Drawbacks​

While selective disclosure strengthens privacy and control, implementing it in real-world systems isn’t always straightforward. Here are some of the common challenges:

• Complexity in Implementation: Selective disclosure relies on advanced cryptographic techniques, often zero-knowledge proofs or similar privacy-preserving protocols. These require careful design, precise execution, and deep security expertise. For developers new to Web3 or cryptography, like myself, the learning curve can be steep, and mistakes in implementation could compromise the intended privacy protections.
• Verification Difficulties: When only a fragment of a credential or statement is revealed, verifying its authenticity can become more complicated. Systems must be designed to ensure that partial disclosures can be trusted without needing access to the complete original data. This often requires additional metadata or proofs to be included, which can increase the overall complexity of the system and potentially slow down the verification process.
• Interoperability Challenges: Not all decentralized identity systems follow the same formats or standards. As a result, credentials issued by one platform may not be easily verifiable on another, especially when using advanced features like selective disclosure. Without widely adopted protocols and infrastructure, cross-platform compatibility can be limited, reducing the broader utility of selectively disclosed data.

While these challenges are real, they’re not insurmountable. Much of the current work in privacy-preserving blockchain development, including projects like Midnight, focuses on making selective disclosure more practical, developer-friendly, and interoperable across various ecosystems.

Use Cases of Selective Disclosure​

Selective disclosure has powerful, real-world applications wherever individuals or organizations need to prove something without oversharing. It’s beneficial in systems that handle sensitive data but also require compliance, trust, and transparency. Here are a few domains where it shines:

• Digital Identity Verification: Imagine proving you're over 18 to access a service—without uploading your driver's license or disclosing your full birthdate and address. Selective disclosure lets you present only the relevant fact (e.g., “over 18”) as a verifiable statement, not the whole credential.
• Financial Transactions: Financial platforms often need to confirm identity or transaction legitimacy (for KYC/AML compliance), but users shouldn’t have to share their entire financial history or wallet activity. Selective disclosure enables sharing only what’s legally necessary—no more, no less.
• Healthcare: Patients may need to prove their vaccination status or medical eligibility without disclosing their entire health record. Selective disclosure lets them share only the required attribute (e.g., “vaccinated for X”) while keeping the rest private.
• Access Control: Whether entering a venue or accessing online services, users may be granted or denied access based on attributes like membership, role, or credentials. Selective disclosure can enforce this access logic without revealing unnecessary identifying information.

Selective Disclosure in the Midnight Network​

At Midnight, selective disclosure isn’t just a privacy feature—it’s a core design principle grounded in rational privacy. Rational privacy recognizes that while sensitive data must be protected, real-world applications also require controlled visibility for regulatory, legal, or operational reasons.

Take financial transactions, for example. A decentralized financial platform built on Midnight may want to keep user balances, transfers, and transaction histories private. However, under anti-money laundering (AML) or know-your-customer (KYC) regulations, certain information may need to be revealed—but only to authorized parties, and only under specific legal conditions.

This is where selective disclosure and zero-knowledge proofs come together. Using Midnight's Compact smart contract language, developers can build logic that proves a transaction is valid (e.g., below a certain threshold, or compliant with regulatory filters) without revealing the full transaction details. Meanwhile, if a regulatory audit is triggered, users or auditors could selectively disclose the required pieces of information—nothing more.

In this way, Midnight enables builders to create applications that respect individual privacy and comply with regulatory requirements. It’s a practical application of selective disclosure that mirrors how real-world trust operates: share only what’s needed, only when it’s needed, and only with the right people.

Conclusion​

Selective disclosure offers a flexible and powerful approach to privacy—one that meets people where they are, allowing them to control their information. It enables individuals to share just enough information to satisfy requirements, without exposing more than necessary. Whether you're verifying an identity, proving a credential, or complying with financial regulations, selective disclosure makes privacy practical and effective.

At Midnight, this concept becomes more than theoretical. It’s embedded into the platform’s architecture through Compact smart contracts and zero-knowledge proofs, allowing builders to create systems that balance user protection with real-world needs. It’s rational privacy in action.

If you're exploring how to build for privacy in Web3—or just learning how these systems work—I encourage you to check out the Midnight docs and Academy for more examples and technical insight, as well as a detailed list of further reading about selective disclosure below:

• What Is Selective Disclosure? – Identity.com
• Selective Disclosure Guide – Dock.io
• A Refresher on Selective Disclosure and Anti-Fraud Rules – Frost Brown Todd
• Midnight Academy Module 3 – Midnight Docs
• Explicit Disclosure Reference – Midnight Docs
• Digital Assets Use Cases – Midnight Docs

And, as always, if you’ve come across any great learning resources on privacy or identity in Web3, I’d love to see them—drop a comment or reply with your favorites!

I'll be back next week with more insights as I continue unpacking the key building blocks that make decentralized systems work.

These two topics sit at the heart of blockchain's promise—ensuring transparency, verifying data integrity, and enabling decentralized governance. I've broken down the key takeaways below, and if you're curious to go deeper, check out the list of helpful resources I've included at the end.

Merkle Trees: Ensuring Data Integrity​

A Merkle Tree, also known as a hash tree, is a data structure that enables efficient and secure verification of large data sets. At its core, it is a special kind of binary tree—a structure many Web2 developers will recognize. In a binary tree, each node has at most two children. What makes Merkle Trees different is that instead of storing values directly, they store hashes. These hashes represent data blocks and provide a compact, tamper-evident summary of all the data in the tree.

Merkle Trees are crucial in blockchain because they allow a large set of data (like thousands of transactions) to be verified efficiently and securely. Instead of needing to check every transaction, you only need a small subset of hashes (called a Merkle proof) to confirm that a transaction is part of a block.

Here's a simplified breakdown of how a Merkle Tree is built:

1. Start with data blocks (like transactions in a block).
2. Each data block is hashed individually. These hashes become the leaf nodes.
3. Pairs of leaf hashes are then hashed together to form the next level of the tree.
4. This process continues, combining hashes pairwise and moving up the tree until you're left with a single root hash, often called the Merkle Root.

In short, each leaf node contains the hash of a data block, each non-leaf node contains the hash of its child nodes, and the root hash represents the entire data set. Any change to any single data block will change its hash, which then cascades up the tree, altering the Merkle Root. This property is crucial for blockchain systems, where data immutability and integrity are paramount.

In practice, Merkle Trees are used in:

• Blockchain Transactions: Ensuring that transactions within a block are untampered.
• Proof of Reserves: Cryptocurrency exchanges use Merkle Trees to prove they hold sufficient assets to cover user deposits without revealing individual account balances.

DAOs: Redefining Organizational Governance​

Decentralized Autonomous Organizations (DAOs) are organizations governed by smart contracts on a blockchain, eliminating the need for centralized leadership. They replace traditional top-down leadership with transparent, community-driven governance, all enforced through code—specifically, smart contracts.

In a DAO, rules and operations are programmed upfront and stored on-chain. That means anyone can inspect how decisions are made, how funds are allocated, and how proposals are handled. Everything is transparent and auditable by default. Instead of a single CEO or board, decisions are made collectively by the community. Token holders can vote on proposals, and the outcome reflects the weight of their stake in the project. This collective decision-making process is what makes DAOs decentralized by design. And because those rules are enforced automatically by smart contracts, DAOs can operate autonomously without relying on manual intervention or centralized gatekeepers. Once a proposal passes, the smart contract executes the decision just as it was coded—no waiting for someone to push a button.

However, DAOs also face challenges, including:

• Security Risks: Vulnerabilities in smart contracts can be exploited.
• Governance Issues: Low voter participation and token concentration can lead to centralization.

DAOs have been utilized in various domains, such as:

• Investment Funds: Pooling resources to invest in projects collectively.
• Charitable Organizations: Deciding on fund allocation through member voting.
• Protocol Governance: Managing and updating blockchain protocols.

How DAO Voting Works (The Simple Version)​

Most DAOs use token-based voting to reach decisions:

1. Members hold a governance token, which gives them the right to vote.
2. A proposal is submitted (for example, "Fund a new development project").
3. Token holders vote for or against the proposal.
4. If a certain threshold is reached (like a quorum or majority), the proposal is accepted and automatically executed by smart contracts.

Beyond on-chain voting, many DAOs utilize off-chain governance platforms, such as Snapshot (widely used for token-weighted voting), Aragon Voice, Tally (commonly paired with Governor contracts), or Coordinape (used for decentralized grants and peer voting). These tools offer flexibility, reduce gas costs, and enable more experimental governance setups.

The more tokens you hold, the more voting power you wield. This is similar to how shareholders vote in corporations, but the process is entirely on-chain, without intermediaries.

Some DAOs use quadratic voting or other mechanisms to prevent whales (large holders) from dominating the process, but the core idea remains the same: the community drives the roadmap.

Interplay Between Merkle Trees and DAOs​

While Merkle Trees and DAOs serve different purposes in the blockchain world—one focused on data integrity, the other on governance—they complement each other in powerful ways. Together, DAOs can remain secure, transparent, and efficient even as they scale.

For example, instead of storing a complete list of eligible voters, a DAO can publish a Merkle Root representing that list. Individual voters then submit a short cryptographic proof (a Merkle proof) to confirm they're included. This keeps voting lightweight, private, and verifiable. The same method can be used to verify grant recipients or airdrop eligibility—ensuring integrity while saving space and gas costs.

Merkle Trees also act as a bridge between off-chain and on-chain activity. Whether it's tracking voting done through Snapshot or verifying community identities, these proofs give DAOs a scalable way to maintain trust and transparency—even as they grow.

Merkle Trees provide DAOs with the cryptographic foundation to scale governance without sacrificing transparency or efficiency. Whether it's verifying voter eligibility, proving fund distribution, or bridging off-chain data to on-chain actions, Merkle Trees help DAOs maintain trust and accountability as they grow. It's a powerful example of how foundational blockchain structures support and enhance decentralized decision-making.

Conclusion​

Together, Merkle Trees and DAOs demonstrate how blockchain technology strikes a balance between technical efficiency and community empowerment. Merkle Trees ensure that large sets of data—like transactions, votes, or recipient lists, can be verified quickly and securely. At the same time, DAOs introduce a way for communities to govern decentralized projects in a transparent and fair manner. When combined, they offer a practical solution for scaling trust without sacrificing decentralization. Whether you're verifying a vote, distributing funds, or proving membership, these tools help build the infrastructure that makes Web3 more than just a technological shift—it becomes a new model for how people coordinate, decide, and build together.

Exploring beyond the Cardano and Midnight Academies for the first time in this journey provided me with a broader understanding of how these technologies are explained and applied across the space. If you're learning along with me or want to dig deeper into any of the topics covered, here are some of the materials I found especially helpful:

• Video: Merkle Trees Explained – Simply Explained
• Introduction to Merkle Trees – Geeks for Geeks
• What Are DAOs – LimeChain Blog
• Blockchain Transparency: Merkle Trees & Proof of Reserves – Moralis
• Everything You Need to Know About Merkle Trees – Bitpanda Academy
• Introduction to DAOs – Chainalysis

And if you’ve come across other great resources while learning Web3 basics, I’d love to hear them—drop a comment or reply with your favorites! You can also check out the Midnight docs for more technical deep dives and real-world use cases.

Stay tuned for next week's exploration into other core components of the decentralized world.

I’m still in the early stages of my Web3 learning journey (see my previous posts on the Midnight Dev Diaries!), and each week unveils new insights and "aha" moments for me. This week, I delved deeper into the Intro to Blockchain section of Cardano Academy, along with Module 1 of the Midnight Developer Academy. Rather than just focusing on the technical aspects and step-by-step guides, I shifted my attention to understanding the evolution of blockchain platforms over time, particularly the journey from Bitcoin to more advanced systems like Midnight. This exploration also led me to reflect on the crucial role that tokens play in the functionality and sustainability of decentralized systems. Tokens aren't just mere digital assets; they serve as the economic backbone that incentivizes participation and secures the network. In this post, I want to share two significant topics that helped clarify my understanding this week:

1. How blockchain platforms have progressed from Bitcoin to Midnight
2. How tokens keep decentralized systems running through economic incentives

Let's jump in!

The Evolution of Blockchain Platforms​

When I first heard about blockchain, I mostly associated it with Bitcoin. However, after diving into more educational content, it became clear that this space has undergone multiple waves of innovation, each building on the last. Here's how we got from the first Bitcoin transaction to the emergence of privacy-focused blockchains like Midnight.

Bitcoin (2009): A New Way to Move Money​

Blockchain began with Bitcoin, launched in 2009 by the pseudonymous Satoshi Nakamoto. It introduced the idea of a decentralized, peer-to-peer payment network where anyone could send money without relying on banks or intermediaries. Transactions were validated through proof-of-work and recorded on a public ledger that anyone could inspect—but no one could alter.

This was revolutionary. Bitcoin proved that decentralized digital money was possible—and, in 2010, someone even traded 10,000 BTC for two pizzas. That transaction is now famous for being the first real-world use of Bitcoin and the most expensive pizza ever bought.

Still, Bitcoin was narrowly focused: it could securely transfer value but not much else.

Ethereum (2015): The Rise of Programmable Blockchains​

Ethereum took the core idea of blockchain and expanded it into something far more flexible. It introduced smart contracts—self-executing programs that live on the blockchain and run when certain conditions are met. This turned Ethereum into what its creators called a "world computer": a decentralized platform for building applications that couldn't be shut down or censored.

Ethereum is guided by six key principles:

• Atomicity: All or nothing execution
• Synchrony: Consistent state across nodes
• Provenance: Trackable origins
• Permanence: Durable data storage
• Immortality: Apps that can't be turned off
• Immutability: Data that can't be changed once written

These principles laid the groundwork for DeFi, NFTs, and DAOs, giving rise to an entire ecosystem of decentralized applications. However, this flexibility came with trade-offs, especially around scalability and high transaction fees.

Third-Generation Platforms: Cardano and Beyond​

Enter the third generation of blockchains. These platforms aim to solve the Blockchain Trilemma: how to balance scalability, security, and decentralization—without sacrificing any of them.

Cardano, launched in 2017, is one of the most notable examples. It uses proof-of-stake to reduce energy consumption and improve efficiency. But what stood out most to me is that it was built from the ground up with formal research and peer-reviewed design—a very different approach from its predecessors.

Cardano also addresses security at the protocol level. Unlike Ethereum, where new tokens are created via smart contracts (which can introduce vulnerabilities), tokens on Cardano are treated as native assets. This means they inherit the same security guarantees as the platform's native currency, ADA, and don't require a custom contract to be created or maintained.

Other improvements include:

• Layer 2 scaling solutions like Hydra
• Support for sidechains to improve interoperability
• A focus on sustainability by reducing resource consumption through staking is also needed

Midnight: The Privacy Layer of the Future​

Midnight represents a new phase in blockchain evolution focused on privacy and regulatory compliance.

It uses tools like zero-knowledge proofs to allow data to remain private on a public blockchain. At the same time, it supports selective disclosure, meaning users can prove compliance (for example, with regulations or audits) without revealing everything. In other words, Midnight blends the decentralization and transparency of blockchain with the privacy needed for real-world use cases—whether it's secure communication, confidential data sharing, or regulated financial applications.

Tokenomics 101: Why Tokens Are More Than Just Coins​

Once I understood how blockchains evolved, the next big question was: How do they keep running without a central company in charge? The answer lies in tokenomics, the economic design behind each network.

Tokens as Utility​

Every blockchain has a native token—Bitcoin has BTC, Ethereum has ETH, Cardano has ADA. But tokens aren't just money. Tokens are used to pay transaction fees, deploy contracts, access network features, and more.

This creates a built-in incentive system. If using the network requires tokens, and the network is valuable, then tokens have value too.

Tokens as Incentives​

Blockchain networks need participants to validate transactions, secure the network, and maintain consensus. In return, they reward those participants with tokens.

For example:

• Miners earn BTC for adding blocks to the Bitcoin chain.
• Validators earn ADA in Cardano's proof-of-stake system to secure the network.

These rewards are often inflationary, meaning new tokens are regularly minted and distributed. However, that inflation funds the network's infrastructure.

Tokens as Governance Tools​

Some tokens also allow holders to vote on decisions. In DAO-style systems, governance tokens let users decide protocol upgrades, fee structures, or treasury spending. This turns token holders into active stakeholders, not just passive investors.

Inflationary vs. Deflationary Models​

The way a token's supply is designed can shape behavior:

• Inflationary models (e.g., Polkadot) continually mint new tokens to incentivize active participation.
• Deflationary models (e.g., Bitcoin) cap the total supply or burn tokens to reduce circulation.

Each model has trade-offs: Inflation can reward contributors but reduce long-term value, while deflation can increase scarcity but discourage spending.

Many modern projects use hybrid models. For example, Ethereum burns a portion of transaction fees to offset inflation while still issuing new tokens to validators.

Conclusion​

Understanding where blockchain originated and how tokens drive these systems provided me with a much clearer view of the ecosystem I'm entering. It's not just about code or decentralization for its sake. It's about designing systems where people are economically motivated to do the right thing. And just like the technology itself, the economics behind blockchains are still evolving.

If you're learning Web3 too or just curious how all the pieces fit together, be sure to take a look at the Midnight docs, Dev Diaries, and the newly published modules in the Midnight Developer Academy.

More foundational concepts are coming next week—stay tuned!