Forem: Devs of Midnight

Midnight network is live

Lauren Lee — Mon, 30 Mar 2026 14:28:04 +0000

The Midnight network is officially live. This milestone marks the introduction of state continuity and permanence in the network and is a significant achievement for everyone involved. This launch follows years of research, development, and collaboration to develop the fourth generation of blockchain technology to deliver end-to-end privacy that is flexible and enforceable at the protocol level. Scientists, engineers, developers, partners, and the community all made substantial and ongoing contributions to the development of the network from its inception.

The genesis block marks both a culmination of building toward the network launch and the starting point for the next phase of on-chain network activity. Developers, partners, and institutions will be able to deploy applications and migrate assets on Midnight. This launch triggers the next stage of network and ecosystem expansion as more Midnight-native tools and services come online that will enable end-to-end programmable privacy.

Scaling real-world use with fourth-generation blockchain

Midnight, the world's first fourth generation of blockchain addresses the fundamental barriers that have prevented blockchain from supporting the real world at scale. Applications in the real world require the ability to protect sensitive data, execute compliance logic on-chain, and make blockchain as accessible as any other technology. Midnight is designed to solve all three.

Outlining the journey and roadmap from the first bitcoin transaction to Midnight’s fourth-generation technology, Founder of Input Output Charles Hoskinson explained how we got to the fourth generation of blockchain: "Satoshi gave us good money; Ethereum gave us programmability; Cardano brought the third generation of interoperability, scale and good governance. Midnight gives us our identity and privacy back”.

While the previous generations of blockchains achieved scale and programmability, and sparked waves of innovation, they did so on public ledgers. This is why the vast majority of the world’s value remains off-chain. Trillions in real estate, private equity, debt and currency cannot yet be digitized. The lack of privacy and unpredictability of the infrastructure makes digitizing and tokenising their assets an existential risk to institutions and the value they hold.

Midnight can remove the final hurdle to bringing the world’s economy on-chain. Midnight gives everyone the capability and opportunity to digitize all the world’s value.

Unlocking Real-world privacy

For blockchain to support regulated activity, on-chain privacy must be programmable. Midnight allows developers to determine when to apply privacy across both application and transaction layers. This is achieved through a technical architecture that prioritizes data sovereignty and cryptographic verification:

Hybrid Ledger Architecture: Midnight uniquely combines both public and private data, enabling applications to process and verify sensitive personal, financial, and commercial information without the data ever being exposed to the network.
Client-side proofs: Sensitive data stays on the user’s device where it belongs. Using a local proof server, zero-knowledge proofs are generated on the user's machine and submitted to the network for validation, meaning identity, eligibility, credit, and compliance verification can happen without the underlying data ever leaving the user's hands.
Shielded & Unshielded Assets: Midnight introduces shielded and unshielded assets, giving developers flexibility over if information is shared on-chain. Shielded assets keep balances, counterparties, and transaction flows off the public ledger. Unshielded assets provide the tools for open collaboration and exchange. Confidentiality and auditability are not a choice between one or the other — on Midnight, you have both.
Selective Disclosure: Compliance logic can be programmed directly into an application, defining exactly when transaction information must be revealed and to whom. Authorised participants including counterparties, auditors, regulators can be granted visibility into specific records without accessing the underlying data that initiated the transaction. This feature enables identity verification, regulatory checks, and eligibility conditions to be validated on-chain without exposing the underlying data. Abstracting away the underlying zero-knowledge cryptography, Midnight empowers developers to focus on application logic while providing users with real-world privacy.

Sustainable costs and predictability

Token volatility makes existing blockchain infrastructure commercially unworkable for many real-world use cases. Transaction fees paid in a network's native asset expose operational costs to market price movements, preventing businesses from accurately forecasting operational costs.

Midnight architecture resolves this through a dual-component economic model. Separating the asset used to govern and secure the network from the resource used to pay for transactions ensures operational costs remain predictable. The Midnight network opens up a path toward a future where users no longer need to hold or manage volatile crypto assets to use the network.

Aligning incentives with dual-component tokenomics

Midnight uses a dual-component economic model designed to align the incentives of users, builders, and validators.

NIGHT for utility and governance

NIGHT is the generator for the network’s operational resource, DUST. NIGHT is the unshielded ledger-native governance and utility token. NIGHT generates the DUST resource, which means NIGHT functions as a store of value for the ecosystem without being consumed by daily transactions. NIGHT is also intended to grant governance rights to holders.

DUST is the renewable network resource

DUST is the resource required to power transactions. Unlike traditional gas models where tokens are burned or paid out, DUST operates on a recharge model similar to a battery.

Generation: DUST is generated proportionally to NIGHT holdings. A NIGHT holder can register NIGHT to generate DUST and designate a recipient to power transactions on the network. That gives NIGHT holders flexibility to choose how to designate their DUST resources.
Sustainability: DUST regenerates over time until it reaches capacity based on the amount of NIGHT held. It takes seven days for a DUST address to reach full charge, whereas partial recharges take proportionally less time.
Self-funding applications: Developers can hold NIGHT to generate the DUST required to cover transaction costs for their users. This allows for applications where the end-user does not need to own or even be aware of the underlying tokens to interact with the service.

Abstracting away complexity with Compact programming language

To make advanced cryptography accessible, Midnight uses Compact, a statically-typed domain-specific language (DSL) based on TypeScript. Compact allows developers to manage both private and public states within a single contract. By using familiar syntax, the language removes the requirement for specialized expertise in ZK proof cryptography, enabling more efficient development of sophisticated logic.

The design of Compact focuses on lowering the technical barrier to building privacy-enhancing technology. Learn more about Compact in the Midnight documentation.

Launching alongside leading institutions

The Midnight network launch represents the primary milestone of the current development phase, which focuses on strengthening infrastructure and achieving operational stability and security. During this stage, the network expands to include distinct federated node operators that collectively operate the protocol under explicit rules for participation and coordination.

While these operators already support the Midnight Preprod network, their participation in the Midnight network launch provides the secure, enterprise-grade foundation necessary for live applications to function. By involving leading global institutions, the Midnight Foundation ensures that infrastructure is managed by operators with proven experience handling high-volume, mission-critical data.

Charles Hoskinson explains, “Midnight is the first public blockchain that gives the world the infrastructure it needs to come on-chain — without sacrificing privacy or compliance. Launching alongside partners like Google Cloud and MoneyGram is a monumental step. For the first time, organisations of this scale have committed not only to running critical infrastructure but also to building and deploying live applications on a public network.”

Learn more about the federated node partners supporting the network including Worldpay, Bullish, MoneyGram, Pairpoint by Vodafone, eToro, AlphaTON Capital, Google Cloud, Blockdaemon, and Shielded Technologies.

Multiphase roll-out strategy for stability and security

The rollout of the Midnight network from genesis block follows a structured multi-phase path to decentralization, and will begin with an initial phased application deployment rollout period to ensure operational stability and security. This is essentially an early phase where developers and applications can access the network’s functionality within a protected environment.

This structured approach allows users to have more confidence that the early DApps and services launching on the network are from developers who have met rigorous readiness criteria.

To maintain this security during the initial phase:

Development best practices: The Midnight Preprod environment is a mirror of the Midnight network. As is common development best practice, all developers should test and deploy to the Preprod environment first to ensure application logic is fully optimized before moving to production.
Infrastructure resilience: Federated node operators are protected by a private protected network. This architecture creates a secure, encrypted communication layer, making the network's core infrastructure resilient against potential external attacks. Fahmi Syed, President of the Midnight Foundation explains the multiphase strategy: “This rollout will be phased, reflecting the importance of introducing privacy-enhancing infrastructure in a deliberate and resilient way. More importantly, this creates the foundations for an entirely new class of on-chain activity. When privacy is built into the system itself, it becomes possible to bring real-world activity and assets on-chain without exposing the underlying data — unlocking entirely new forms of economic value that were previously impossible on transparent infrastructure.”

Progressive decentralization

As stewards of the network, the Midnight Foundation intends to transition from this federated model to a fully decentralized network. This path to decentralization is designed to be managed thoughtfully and responsibly, ensuring the network maintains security and stability as it matures. This planned evolution allows the ecosystem to scale while moving toward a fully decentralized and permissionless state in subsequent phases of the roadmap.

What to do next…

The Midnight network launch is a significant milestone that initiates the next phase of ecosystem growth. This release provides the foundation for a wide range of privacy-preserving applications and institutional integrations.

See live network metrics at Midnight Explorer.

Join the community on Discord.

Check the Midnight blog regularly for more news and information.

Get your project on the map

Lauren Lee — Fri, 06 Mar 2026 12:40:58 +0000

Three quick updates to make sure your work is visible, counted, and recognized as part of the Midnight ecosystem.

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.

TL;DR: Midnight's developer ecosystem is real and growing. These three steps make sure that growth is visible to the tools and reports that the wider industry pays attention to.

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:

Go to your repository on GitHub
In the right-hand sidebar, find the About section
Click the ⚙️ gear icon next to it
In the Topics field, add the relevant topics from the table below
Click Save changes

Topic	When to use
`midnightntwrk`	Required for all Midnight ecosystem projects
`compact`	Add only if your project uses the Compact language

Do not use: midnight, midnight-network, midnight-compact, or midnight-ecosystem. These variants are not tracked and will not associate your project with the ecosystem.

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.

Your project type	Attribution sentence
dApps, contracts, or tooling that run directly on Midnight	"This project is built on the Midnight Network."
SDKs, infrastructure, wallets, or services	"This project integrates with the Midnight Network."
Developer tooling, frameworks, or libraries	"This project extends the Midnight Network with additional developer tooling."

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.

Aliit Fellowship Now Accepting Cohort 2 Applications

Lauren Lee — Thu, 05 Mar 2026 14:48:25 +0000

The Aliit Fellowship, the technical contributor program for the Midnight network, is now accepting applications for Cohort 2. Cohort 1 is active. The program has evolved. Here's everything you need to know before you apply.

The Aliit Fellowship serves as the primary hub for hands-on contribution to Midnight. The Aliit prioritizes technical expertise and ecosystem development. Fellows engage directly with the protocol, create essential tooling, and produce the documentation required to make zero-knowledge (ZK) technology accessible. Alongside core development, the Fellowship includes dedicated tracks for Education, Advocacy, and Community Leadership which are inclusive of different types of contributions.

Following the successful launch of Cohort 1, the Fellowship has transitioned to a rolling admission model to better integrate contributors as they ready their projects. Applications for Cohort 2 are now open.

About the Aliit

The Aliit is Midnight's technical fellowship. It exists for developers who are actively contributing to the ecosystem in meaningful, hands-on ways, whether through code, tooling, documentation, support, or other technically grounded work.

The Aliit Fellowship focuses on the technical development of the network rather than social or community reach. While the Nightforce program supports community growth and visibility, the Aliit supports contributors who strengthen the technical core of the ecosystem.

The Aliit Fellowship is looking for contributors who operate with good technical judgment, communicate clearly, and are willing to help unblock others. This Fellowship is built on trust and responsibility.

The Candidacy Structure

The Aliit Fellowship now runs on a four-stage path:

Candidate is where you begin. This is a two-month phase structured within Zealy, with updated quests designed to surface how you think, what you build, and how you show up for the community. Applications to become a Candidate are reviewed on a rolling weekly basis. You can apply to become a Candidate at any point.
Tier 1 Fellow is the entry point for the Fellowship. If you're accepted into Cohort 2, you’ll become a Tier 1 Fellow. Cohort 1, which graduated from Cohort 0, are already Tier 1 Fellows. This stage is a four-month commitment, and it's where you'll establish your rhythm of contribution and build alongside the existing Fellows.
Tier 2 Fellow runs for six months and carries you through the end of the year. Members who progress to Tier 2 have demonstrated consistency and are embedded more deeply in the work of the ecosystem.
Tier 3 Fellow opens in January 2027. We'll share more about what this looks like as the year develops.

How Contribution Works: The Four Personas

One of the most significant changes in this iteration is the introduction of contribution personas. Rather than prescribing a single mode of participation, we've defined four lanes that reflect how real technical contributors actually work.

Builder is the default for every member. This covers development work, tooling, protocol contributions, and anything living in GitHub.
Educator is for members who create tutorials, run workshops, write documentation, or help other developers understand complex concepts. If you're the person who makes ZK proofs feel approachable, this is your lane.
Advocate covers talks, content creation, and activities that bring new developers into the Midnight ecosystem. If you're actively representing Midnight at events or through original content, this is where that work counts.
Community Leader recognizes members who organize events, provide ongoing support in developer channels, and help coordinate the broader builder community.

You're not locked to one persona. Each month, you self-report where your contributions landed across as many lanes as apply to you. The reporting is lightweight: GitHub activity plus a monthly summary, nothing more.

Benefits of Fellowship

The Fellowship provides resources and benefits tailored specifically to technical contributors. Candidates receive access to an exclusive Discord channel and an NFT while in the queue. Fellows receive a package designed to support technical, personal and professional development alongside ecosystem growth including: welcome swag, developer tool credits, NFTs, dedicated Discord access, community spotlight opportunities, fireside speaking slots, public speaking coaching, and conference credits.

The further you progress, the more the Fellowship supports your ongoing development . Tier 3 Fellows will receive NIGHT rewards on top of all other benefits. More details on that will come as mainnet approaches.

How Admissions Work

Applications are accepted on a rolling basis and reviewed weekly. There is no batch deadline. If you're ready, you can apply now.

During the Candidate phase, we're paying attention to how you engage with the updated Zealy quests, the quality of your contributions in Discord and the developer channels, and how you show up for other builders. Admission decisions reflect that whole picture.

Once accepted into Tier 1, you'll receive an onboarding from the team and be connected with the existing Fellows. The program is designed to be genuinely collaborative, not just a credential.

This program was built because Midnight is early, complex, and evolving. The Aliit exists to catch issues early, improve clarity, and help other builders move forward. If that kind of work is what you're already doing, you belong here.

How to apply

The admission process operates on a rolling basis, with Candidate applications undergoing regular review. The first formal review of this Candidate pool occurs at the end of April, with official onboarding for Cohort 2 beginning on May 1.

Early application ensures candidates have sufficient time to establish a record of contribution before the April review.

If you have questions before applying, drop them in the Midnight Discord. The Fellows and the DevRel team are present and responsive.

Apply to be part of Cohort 2 here.

Midnight MCP - AI-assisted development for Compact smart contracts

Idris Olubisi💡 — Tue, 24 Feb 2026 13:03:27 +0000

AI coding assistants like Claude, GitHub Copilot, and Cursor have transformed how developers write code. But they have a fundamental limitation: they only know what was in their training data.

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:

The AI assistant calls midnight-get-latest-syntax to retrieve current Compact syntax.
It generates code using the correct patterns.
It calls midnight-compile-contract to validate against the real compiler.
If compilation fails, it reads the error, fixes the code, and retries.
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.

Tool	Purpose
`midnight-search-compact`	Search Compact language code across indexed repos
`midnight-search-docs`	Search official Midnight documentation
`midnight-search-typescript`	Search TypeScript SDK implementations
`midnight-fetch-docs`	Fetch live documentation from docs.midnight.network

Analysis tools

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

Tool	Purpose
`midnight-compile-contract`	Validate code against the real Compact compiler
`midnight-analyze-contract`	Run 15 static security checks
`midnight-review-contract`	AI-powered security review
`midnight-extract-contract-structure`	Parse contract structure and exports

Generation tools

Use these tools to create new contracts and documentation.

Tool	Purpose
`midnight-generate-contract`	Generate contracts from natural language descriptions
`midnight-document-contract`	Generate documentation in Markdown or JSDoc format

Repository tools

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

Tool	Purpose
`midnight-get-file`	Retrieve files from any indexed Midnight repository
`midnight-get-file-at-version`	Get file content at a specific version
`midnight-compare-syntax`	Compare syntax between Compact versions
`midnight-get-latest-syntax`	Current Compact syntax reference
`midnight-get-repo-context`	Everything needed to start coding (compound tool)
`midnight-list-examples`	List available example contracts

Version management tools

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

Tool	Purpose
`midnight-upgrade-check`	Full upgrade analysis (compound tool)
`midnight-check-breaking-changes`	Identify breaking changes between versions
`midnight-get-migration-guide`	Step-by-step migration instructions

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.

DevRel When the Ecosystem Is Still Taking Shape

Lauren Lee — Mon, 02 Feb 2026 07:22:01 +0000

What actually works in early-stage developer ecosystems

DevRel looks different when developers are building on systems that are still changing underneath them.

Leading Developer Relations at Midnight has meant building an ecosystem from scratch, before launch, while the product is still taking shape underneath us.

It has been one of the most challenging and instructive experiences of my career. This is my first time leading DevRel pre-launch, with real users, real incentives, and real consequences when things break. When nothing is stable yet, every assumption about DevRel gets pressure-tested fast.

What actually helps developers move forward becomes very clear, very quickly.

As we get closer to taking the chain live, these patterns have become impossible to ignore.

Building before launch, with real developers and real consequences.

In early 2025, I wrote an article about DevRel at Midnight as a systems problem. Flywheels, journeys, scaffolding for scale. That thinking still holds.

What changed is that we stopped designing in the abstract and started operating those systems with real developers, real incentives, and real breakage. Some assumptions held. Others collapsed fast.

This post is not a replacement for that earlier strategy. It is what survived contact with reality.

For context, here’s the original piece: DevRel in Web3: Building Systems that Scale While the Ecosystem is Still Taking Shape.

1. Engagement programs are only valuable if they create directional movement

Healthy ecosystems help developers move somewhere, not just participate.

Quests, fellowships, Discords, events, and content have value only when they push developers forward, from curiosity to first build, from contribution to real ownership. Activity without progression is just motion, not momentum.

Early-stage programs must teach something concrete and lead to something tangible. Developers should leave knowing more than they did before and having built something they did not have yesterday.

If a program cannot answer “what does this unlock next?” it is not an engagement strategy. It is marketing noise with better branding.

2. Docs, tooling, and support are converging into a single developer experience

Developers experience your ecosystem as a single surface, no matter how many teams, orgs, or silos exist behind the scenes.

From their perspective, documentation, examples, local tooling, error messages, and support are inseparable parts of one experience. When something breaks, they do not diagnose which team owns it. They just decide whether to keep going.

The ecosystems that feel easy to build on are the ones that design these pieces as a coherent system, not as a collection of disconnected deliverables. Consistency, handoffs, and shared ownership matter more than perfect individual components.

If it feels smooth to the developer, it is because the org did the hard work to make it so.

3. Early-stage DevRel credibility is earned through consistency, not scale

Shipping reliably beats launching big, every time.

Weekly rhythms, predictable programs, clear expectations, and visible follow-through build trust faster than any splashy campaign ever could. It may not look glamorous from the outside, but developers notice when things run on time, work as described, and improve steadily.

Early-stage ecosystems are experiments by definition. The teams that earn trust are not the ones that avoid mistakes, but the ones that ship quickly, acknowledge what did not work, fix it, and keep moving. Momentum comes from iteration, not perfection.

Consistency plus learning beats polish every time.

**4. Early-stage DevRel succeeds or fails on unblocking, not inspiration**

The most effective DevRel teams are not necessarily the loudest but instead are the fastest at removing friction.

At early stages, developers do not churn because they lack motivation. They churn because they hit blockers, and no one clears them quickly enough. The teams that win treat DevRel as an unblocker responsibility first, and storytelling second.

5. Flat teams outperform rigid hierarchies in early ecosystems

When you’re building an ecosystem from zero, no one actually knows what will work yet. The fastest progress comes from teams that invite ideas from everywhere, try things quickly, and course-correct without ego.

We treat DevRel as a continuous experiment. Ideas come from the team, from builders, from the community. We test them. Some land. Many do not. We learn, adjust, and move forward. That is not chaos, it is disciplined adaptation under uncertainty.

Decentralized ecosystems demand this mindset. The community ultimately decides what sticks. The role of DevRel is not to dictate direction, but to create the conditions where good ideas surface, get tested, and scale when they earn it.

Everyone involved brings expertise. Everyone has seen DevRel done well and badly elsewhere. The teams that win are the ones confident enough to listen, humble enough to pivot, and disciplined enough to turn learning into action.

6. Small, well-instrumented communities outperform large, unmeasured ones

You do not need more developers. You need clearer visibility into the ones you already have.

Early-stage ecosystems win when teams can answer simple questions: who is progressing, who is stuck, and why. But insight alone is not enough. What matters is what you do next.

Strong communities turn feedback into action. They intervene when builders hit friction, create new paths when momentum stalls, and give developers clear reasons to keep building and deepening ownership.

Retention does not come from scale. It comes from attention. A smaller group with tight feedback loops, clear progression paths, and visible follow-through will always out-iterate a massive community where signals disappear into the void.

7. DevRel is becoming an operating system, not a job title

The most impactful DevRel work now lives in systems, not individuals.

What scales is not charisma or heroics, but workflows, standards, flywheels, tooling, and feedback loops that keep running week over week. Titles may change, but the work is increasingly about building durable engagement infrastructure.

Early-stage DevRel is less about growth hacks and more about earning trust under uncertainty.

Join the Midnight Conversation

We’d love for you to join this early ecosystem. Hear your feedback and ideas. Drop into Discord, open an issue, or fork a repo and show us what you’ve built.

An invitation to fellow DevRel builders

If you’re doing DevRel in a web3 ecosystem, especially an early one, I’d love to connect.

If you’re building DevRel while the platform is still taking shape, I’d love to compare notes.

What broke faster than you expected? What held up under real usage? What did you stop doing entirely?

--✨👩🏼‍💻 lolocoding

Introduction to the FungibleToken contract on Midnight

Claude Barde — Thu, 11 Sep 2025 14:35:44 +0000

Introduction to the FungibleToken contract on Midnight

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.

1. 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).

2. 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 & 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 & 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

The Midnight Community Board: Building With the Community, Not Just For It

Lauren Lee — Fri, 01 Aug 2025 14:56:44 +0000

I believe a healthy ecosystem isn’t built for a community. It’s built with them.

That’s why the DevRel team at Midnight is thrilled to debut the Community Board, a new GitHub-based hub designed to make collaboration more transparent, inclusive, and efficient.

Just this week, a longtime partner and contributor shared feedback that struck a chord:

“The real frustration hasn’t been the number of channels. It’s not knowing what happens to our ideas or feedback once they’re shared. Without transparency into follow-up, it feels like issues just disappear.”

The Community Board is our solution to that exact problem. It gives developers, partners, and community members visibility into what’s happening with their feedback. And more importantly, a seat at the table to help shape priorities and the opportunity to pick up work themselves.

How the Community Board Works

Submission Flow

Anyone in the community can open an issue in the GitHub Community Hub repository.
Issues cover a range of categories:
- Content Development (blogs, videos, docs, etc.)
- dApp Development (example apps, new features)
- Feature Demo Ideas (including i18n/localization)
- Feature Requests and Suggestions
- Bug Tracking
- Midnight Improvement Proposals (MIPs)

Triage Process

An arbiter committee (currently DevRel, expanding over time to include dApp devs, SPOs, partners, and wallet holders) reviews submissions.
Submissions are given clear statuses: Needs Discussion, Triaged, Rejected.
Triage happens transparently, either live during Fireside Hangs or asynchronously on GitHub.

Grab-and-Go Board

Triaged issues move into the Grab-and-Go Board, a curated space for vetted ideas.
From here, contributors can claim work:
- DevRel team members
- Partners
- Ambassadors
- Ecosystem builders and developers

Community Voting

Issues on the Grab-and-Go Board can be upvoted with emoji reactions.
Voting provides constituency-driven signals, helping us prioritize based on real demand.

Execution and Integration

Picked-up issues flow through columns:

To Do → In Progress → Needs Review → Done.

Where needed, issues flagged for internal ownership move to the engineering teams' Jira board.
Over time, the Community Board could become a central part of the Midnight Improvement Proposal (MIP) process.

Automation

GitHub Actions automatically label issues, move them into the right boards, and reduce manual overhead, keeping the workflow fast and efficient.

Why this matters

Ends fragmentation: One place for all community ideas and feedback
Provides visibility: Everyone can see what stage a submission is in
Enables contribution: Community members can pick up vetted tasks directly
Democratizes prioritization: Voting ensures the roadmap reflects community demand
Broadens our builder base: Reduces pressure on core teams and grows a contributor ecosystem
Streamlines collaboration: Clear swimlanes, automation, and transparent triage keep the process efficient

This is still a work in progress, and we’ll continue refining it. But it’s a big step toward making Midnight a truly builder-driven ecosystem.

👉 Watch an overview/explainer video

👉 Explore the Community Board on GitHub

A huge thank you to Stevan Lohja and the DevRel team for building this, and to our community members for not just sharing feedback but leaning in to build alongside us. Together, we’re proving that privacy-first technology can be built in public, by and for the builders who believe in it. 🌱

Learning Web3 from the Ground Up: Understanding Ethereum

Samantha Holstine — Fri, 25 Jul 2025 15:09:00 +0000

This past week, I started the SheFi course— a program designed to help women dive deeper into Web3 and decentralized finance. One of the first topics it covered was Ethereum: what it is, why it matters, and how it fits into the broader decentralized ecosystem.

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.

Learning Web3 From the Ground Up: What Are Zero-Knowledge Proofs (ZKPs)?

Samantha Holstine — Mon, 21 Jul 2025 17:20:09 +0000

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:

Setup: A circuit is created. A proving key and a verifying key are generated.
Proof Generation: The prover uses their secret (a witness) and the proving key to generate a cryptographic proof.
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:

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!

Say Hello to example-counter and example-bboard

Lauren Lee — Tue, 15 Jul 2025 10:45:00 +0000

Midnight's Developer Relations team is actively shaping how developers learn, build, and experiment with privacy-first apps. In this post, we take a closer look at how DevRel is lowering the barrier to entry for new builders, supporting open-source tools, and helping the community navigate the unique challenges of developing on a privacy-preserving blockchain.

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.

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

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.

Learning Web3 from the Ground Up: Smart Contracts and the Compact Language

Samantha Holstine — Fri, 20 Jun 2025 16:39:59 +0000

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.

Learning Web3 From the Ground Up: Understanding Selective Disclosure

Samantha Holstine — Fri, 13 Jun 2025 20:44:47 +0000

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.

Forem: Devs of Midnight

Midnight network is live

Scaling real-world use with fourth-generation blockchain

Unlocking Real-world privacy

Sustainable costs and predictability

Aligning incentives with dual-component tokenomics

NIGHT for utility and governance

DUST is the renewable network resource

Abstracting away complexity with Compact programming language

Launching alongside leading institutions

Multiphase roll-out strategy for stability and security

Progressive decentralization

What to do next…

Get your project on the map

Why this matters

The attribution process

Compounding developer results

Step 1: Add GitHub topics

Step 2: Add one attribution sentence to your README

Step 3: Open a PR to the Awesome dApps list

Earn Zealy points while you're at it!

Three steps, once per repo, permanent record

Aliit Fellowship Now Accepting Cohort 2 Applications

About the Aliit

The Candidacy Structure

How Contribution Works: The Four Personas

Benefits of Fellowship

How Admissions Work

How to apply

Midnight MCP - AI-assisted development for Compact smart contracts

What is MCP?

The problem with AI-generated Compact code

Install Midnight MCP

Claude Desktop

Cursor

VS Code with GitHub Copilot

How Midnight MCP works

Real compiler integration

Graceful fallback

Semantic search across 102 repositories

29+ tools for Midnight development

Search tools

Analysis tools

Generation tools

Repository tools

Version management tools

Resources and prompts

Architecture

What's next

Learn more

DevRel When the Ecosystem Is Still Taking Shape

DevRel looks different when developers are building on systems that are still changing underneath them.

1. Engagement programs are only valuable if they create directional movement

2. Docs, tooling, and support are converging into a single developer experience

3. Early-stage DevRel credibility is earned through consistency, not scale

4. Early-stage DevRel succeeds or fails on unblocking, not inspiration

5. Flat teams outperform rigid hierarchies in early ecosystems

6. Small, well-instrumented communities outperform large, unmeasured ones

7. DevRel is becoming an operating system, not a job title

Early-stage DevRel is less about growth hacks and more about earning trust under uncertainty.

Join the Midnight Conversation

An invitation to fellow DevRel builders

--✨👩🏼‍💻 lolocoding

Introduction to the FungibleToken contract on Midnight

Introduction to the FungibleToken contract on Midnight

Features of the FungibleToken Contract

1. Ledger State Variables

2. Entry Points and Circuits

Initialization & metadata

The transfer family

Allowances (approve / spend / transferFrom)

Minting and burning

Safety & utility glue (from Utils and Initializable)

How the pieces fit together

Conclusion

Links

The Midnight Community Board: Building *With* the Community, Not Just For It

How the Community Board Works

Why this matters

Learning Web3 from the Ground Up: Understanding Ethereum

**4. Early-stage DevRel succeeds or fails on unblocking, not inspiration**

Safety & utility glue (from `Utils` and `Initializable`)

The Midnight Community Board: Building With the Community, Not Just For It