Skip to main content

7 posts tagged with "intro"

View All Tags

· 6 min read
Samantha Holstine

As I continue my journey through the world of Web3, I’ve been digging into the building blocks that make privacy-first platforms like Midnight possible (you can catch up on previous posts in the Midnight Dev Diaries!). This week, I focused on two foundational pieces that go hand in hand: smart contracts on Midnight and the Compact language that powers them.

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.

· 9 min read
Samantha Holstine

As I delve deeper into the world of Web3, I've been working my way through foundational concepts to have a better understanding of the industry (check out my last five posts on the Midnight Dev Diaries!). This week, I dove into one of the most practical and privacy-focused ideas I’ve encountered so far: selective disclosure.

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:

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.

· 7 min read
Samantha Holstine

As I continue my Web3 learning journey, I've mostly been working through Cardano Academy and Midnight Academy and documenting my findings in the Midnight Dev Diaries. But this week, I decided to branch out and explore a broader range of beginner-friendly resources across the ecosystem. That led me to two foundational concepts that kept coming up: Merkle Trees and Decentralized Autonomous Organizations (DAOs).

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:

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.

Feedback