DEV Community: Lauren Lee👩🏼‍💻

33 broken builds, one agent on each disposable computer. The hard part was deciding what counts as fixed.

Lauren Lee👩🏼‍💻 — Tue, 22 Sep 2026 13:39:46 +0000

First, give it to a robot

Earlier this week, I wrote about how I built a tool to run every submission from a hackathon, all 164 of them, each on its own disposable computer, to find out how many of them actually would run end to end. And a quarter of them didn't.

When a build failed, the tool froze the computer at the moment of failure and kept it. The repository, the installed dependencies, the exact command that broke, its last 40 lines of output. All of it sitting on a machine anyone could open.

I ended that post with advice I had never taken: give the failing hackathon team that machine. Teams almost never get feedback from judges more specific than a score, and here was the whole failure, reproducible, waiting for someone to look.

But before handing those machines to anyone, I handed them to an agent. One instruction, a shell, a time limit, and a question I could check without taking the agent's word for it: Does it build now?

This is what happened, including the parts where the harness was the problem.

What the agent was given

The new tool rewinds each frozen machine to the moment its build failed, installs a coding agent on it, and gives it this:

You are on a machine where a hackathon project failed to build.
The command that failed: <the exact command>
The last lines of its output: <40 lines>

Your job: make that exact command exit 0 with the smallest change you can.
Do not add features. Do not delete or weaken tests. Do not change the build
command to skip work. Do not touch git remotes. Change nothing outside the
repository. If the build depends on a secret or a service you cannot have,
stop and say so instead of faking it.

When the command passes, write FIX.md: two or three sentences a student could
act on. What was wrong, and what you changed.

Then the agent gets to work. When it stops, the harness runs the failing command itself. The agent never grades its own homework. If the command exits 0, the harness measures what changed, reads the note, and freezes the machine again.

The agent runs on the machine, not on my laptop with the machine as a tool.

Fly's pitch for these machines is "computers for agents," and this is what that means in practice: the machine already has the shell, the toolchain, and the broken repo. The harness only asks a question and checks the answer.

The harness enforces 3 rules:

The agent cannot grade itself. The harness reruns the build.
The agent cannot reach the internet except package registries and the model API. The platform enforces that per machine, and a prompt cannot argue with a firewall.
The agent cannot count anything as a fix that changed the toolchain rather than the repository. The harness checks the machine's home directory afterward and flags it.

69 machines, none running. Each one is a broken build frozen where it stopped, or an agent's attempt at it. Idle, they cost nothing.

What 33 broken builds look like when you hand them to an agent

The last post counted 39 build failures. 6 of those turned out to be mine, which I'll come back to. That leaves 33 real ones, and every one of them got the same treatment.

17 of 33 now build. 15 do not. One build hangs for 10 minutes regardless of what anyone does to it.

The fixes were small. Counting only the source lines the agent changed, excluding lockfiles and regenerated artifacts, the median fix was 4 lines. 11 of the 17 were under 10 lines. The largest was 47.

What was actually wrong	Fixed
Generated contract code out of step with the pinned SDK or runtime	4
Compact contract source errors (a literal typed wrong, a missing cast, old assert syntax)	3
Build script only works on Windows (`wsl`, `/mnt/s/...` paths)	2
Wrong path or directory name in a script	2
Code that reaches a database or a service at build time	2
Bundler cannot handle the SDK's wasm without a plugin	1
Type checker told to look away (`@ts-expect-error`)	1
Note missing or unclear	2

The first row is the toolchain drift finding from the last post, this time seen from inside the repositories. Teams generated contract code with one compiler and pinned a runtime from another, or wrote against an SDK version whose exports had since moved. The agent's note on one of them said it plainly: all 3 problems were version and environment mismatches, not logic bugs. That sentence held across most of the 17.

The @ts-expect-error row is counted separately on purpose. The build passes; nothing was fixed. The harness flags it, and I'd want a human to see that flag before anyone calls it a repair.

All 33 machines cost about $7 in model time. The whole project, including every run I got wrong and had to repeat, came to just under $16: $20 credits loaded, $4.02 left.

Two models, same machines

I ran the first 7 machines on the biggest model available and then realized how quickly I was burning through credits, so the other 26 ran on the smallest. That means model and batch are tangled together in the headline numbers, and I can't cleanly separate them. It also produced a comparison I would not otherwise have paid for: I later reran those same 7 machines on the small model.

On the 4 machines with a real bug, the large model fixed 4 of 4. The small model fixed 1 of 4, but only by editing a generated type definition that the next regeneration would overwrite. On the 2 machines where my environment, not their code, caused the failure, the large model refused to touch anything and explained why; the small model changed the team's pinned version to make the error go away.

Cost per machine differed by about 8 times. This is 7 machines, so treat it as an observation and not a rate. The observation is that the cheaper model was fine on one-line fixes and worse at knowing when not to fix something.

What the harness got wrong, in order

The last post's best paragraph was about the tool producing a confident wrong answer. This one has 6.

It restored the wrong checkpoint. The judge had recorded a checkpoint id by trusting the order of a list. The list was not in that order. The first 3 machines were rewound to their factory state, before the repo was cloned, and the agent reported it could not find the directory. The harness logged "agent failed." Nothing had been given to the agent.

The fence blocked the agent's own download. I locked down the network before installing the agent. The agent's installer fetches its binary from a host that is not the package registry. The install "succeeded," left an empty shim on the path, and every run exited silently with nothing recorded. The fix was to install first, prove the agent can answer a question, then close the fence.

The fence turned my limits into their changes. The first real fix I looked at was 94 lines across 4 files. 40 of those lines rewrote how the app loaded fonts because my allowlist didn't include the font host, and the agent routed around it. Same machine, a day later, with the fence corrected: 1 line.

The fence changed the problem on 16 machines. The contract compiler downloads pinned versions of itself from GitHub's API and asset host, and the proving step fetches reference strings from another host. None were allowed. So on every contract-compile failure, the build now failed for a reason the judge had never seen. The large model wrote an "Environment" section naming the host and stopped. The small model symlinked one compiler version over another and, on one machine, edited the compiler's wrapper script in the home directory. The harness now runs the failing command behind the fence before the agent starts and compares the failure with the judge's. If a new host appears, the result is "fence blocked," no agent runs, and I widen the allowlist.

Lines changed was measuring the wrong thing. A 9-line contract fix showed as +289/-84 because the repo commits its generated output and the fix regenerated it. A fix to generated code that the repo ignores showed as 0 lines. Lockfiles added dozens more. The number in this post excludes all 3.

The judge had been wrong the whole time. The agents kept saying the same thing on certain machines: compiler version 0.31.1 is not installed. It wasn't. Those repos pinned a compiler version in their own build scripts, and the compiler doesn't fetch pinned versions on its own. My judge had never installed them. 6 of the 39 "build failures" in the last post, as first published, were my sandbox, not their code. With the pinned versions installed, all 6 build, and 3 pass their tests. I went back and corrected that post in place: 113 of 164 built, not 107, and a quarter rather than nearly a third would not have built elsewhere. If you read it after 21 September, you saw the fixed numbers. The tool that exists to catch confident wrong answers had produced 6 more, and I only found them because a second tool kept tripping over them.

Two days of agent time. Blue is the 7 machines on the large model; orange is the other 29 on the small one.

What this doesn't tell you

Builds is not works. A project that now exists at 0 might still do nothing its README promises. The agent's note might be wrong. I read all 17, and they matched the diffs, but I'm one person and the notes are short.

A fix from an agent is a suggestion, not a commit. Nothing here was pushed anywhere. The machines are still frozen with the changes in the working tree, which is where they belong until a human on the team looks at them.

And the agent only saw what the harness let it see. A fence that is too tight produces fake failures, as I found out 4 times. A fence that is too loose produces an agent with your credentials and a shell. I'd rather rebuild the allowlist than skip it.

The changes I'd make before your next hackathon

Give the failing team the machine, and the note. I've spent years on judging panels handing out scores with a decimal point in them, and I don't think a single team ever learned anything from a 6.5. "Your build failed because the runtime you pinned is two versions behind the compiler that generated your contract" is something a student can fix before dinner. I ended the last post telling organizers to do this. I've now done it, with a robot as the first recipient, and the robot's notes were better than most of the feedback I've written.

Put the fence in the platform, not the prompt. Every agent I ran was told, in plain English, not to route around missing hosts. Some did anyway. The ones that didn't weren't the obedient ones; they were the ones the network stopped. A rule the agent can break is a suggestion. A rule the platform enforces is a rule.

Assume your harness is wrong somewhere, and build the thing that will catch it. The judge was checked by the fixer. The fixer was checked by the diff reader. Each one found a mistake in the one before, and I have no reason to believe the diff reader is the last link. If you run this and find where it's wrong, that's the point, and I'd like to hear about it.

The tool is on GitHub at laurenelee/hackjudge, same repo as before. npm run fix does what this post describes, and the README lists every host the fence allows and why. It cost me $16 and a Sunday. Yours will be cheaper, because you'll skip the parts I got wrong.

Find me @lolocoding👩🏼‍💻

164 disposable computers, one judging afternoon, and a question nobody had time to ask

Lauren Lee👩🏼‍💻 — Fri, 18 Sep 2026 16:16:42 +0000

Does it build?

I have run hackathon judging the careful way. By that I mean: rubrics written before submissions open, 3 judges assigned to each project, scores reconciled in a calibration call, and a technical reviewer for anything in contention for a prize. And in all of that, one question never made the list, because there was never time to ask it of 60 teams: Does it build?

As organizers, we can build a fair and honest process for judging projects. But one thing a weekend hackathon rarely has time to do is build the code. A well-run panel will clone a handful: the ones a reviewer flagged, the ones near the prize line, the one whose README made a claim someone didn't believe. 5 or 6, perhaps, out of the 60. The rest are evaluated on what they claim to do.

No panel is failing here. The clock is, and frankly, so is the math.

Do the math on a judging afternoon

Close your eyes. Picture the standard weekend hackathon. 48 hours, somewhere between 40-80 teams, and at the end an expo: tables in rows, laptops open, a team at each one waiting to demo. Judging happens on foot. Each judge takes a slice of the room and moves table to table: 4-5 minutes each, hear the pitch, watch the demo, ask one question, score on a phone, move on.

5 minutes is enough to hear a story and form a view. It's not enough to clone a repo, install its dependencies, and find out whether the thing you were just shown builds anywhere other than the machine it was shown on. If you tried, you'd finish your slice sometime after the pizza ran out.

A demo that works simply proves that their laptop works.

So the format grew a process shaped by its constraint, and over the years the constraint faded from view. Rubrics grew categories for innovation, presentation, user experience, and sponsor alignment, and rarely a line for "Does it build," because there was no honest way to fill it in for 60 teams before the venue closed. Some ecosystems now compile the smart contract, which is real progress. Almost no one builds the entire project, and the few who do are running 60 strangers' install scripts on their own laptops, where any one of those scripts can read their files, their keys, and their browser sessions😳

The result is a competition that measures the ability to describe software. And yes, that's a real skill. But it's a different skill from building software, and the first has stood in for the second for as long as hackathons have existed. Teams understand this better than anyone, which is why the pitch gets more rehearsal on Sunday afternoon than the build actually does.

For most of my career, that was a fact about the format, like the weekend or the pizza.

Then I spent a week finding out it no longer has to be.

What changed is the price of a computer

I had been messing about with Fly.io's Sprites, which hands you a fresh Linux machine through an API call, bills you by the second, and lets you throw it away when you're done. I wanted an excuse to build something real with them, and the judging problem was sitting right there. If a clean machine costs a fraction of a cent a minute and appears in seconds, "build every submission" stops being a fantasy and becomes a for loop.

So I wrote one. Hand it a list of repositories and, for each one, it creates a machine, clones the repo, works out what kind of project it is, installs the dependencies, compiles whatever there is to compile, runs whatever tests exist, and writes down exactly how far it got.

npm run judge -- --input submissions.csv --executor sprites --concurrency 4

That's the whole tool. The interesting part is what it refuses to do.

What the tool refuses to do

It refuses to give a score. Every submission lands on one rung of a ladder, and the rungs are facts, not subjective opinions.

Rung	Meaning
Unreachable	the repository is gone, private, or was never a repository
Empty	it exists but has no meaningful code
Not evaluable	has code, but needed a toolchain my machine could not obtain; that failure is mine, not theirs
Install failed	dependencies would not install
Build failed	installed, but would not compile or build
Installed, no build	installed; there was nothing to build or check
Built, no tests	built; no tests to run
Tests failed	built; tests exist and fail
Tests passed	built; tests pass

A judge can argue with a score. They can't argue with exit code 2 at line 40 of the type checker.

It refuses to share a machine. A hackathon install script can do anything at all, from writing to your home directory to installing a global package that changes how the next project behaves. Run 60 on one runner, and project 40's result depends on what 1-39 left behind. Run each on a fresh machine, and every result stands independently on its own. That same isolation makes it safe to build a stranger's code: whatever an install script does, it does to a machine you were going to throw away anyway, not to yours.

It refuses to blame the team for my mistakes. If a clone fails because the repository is gone, that's on them. If it fails because my machine couldn't reach GitHub, or didn't have the right compiler installed, that's on me, and the tool says so in a separate category instead of marking the project as broken.

It refuses to throw away a failure. When a build breaks, the machine is checkpointed and kept, frozen at the moment it broke. Anyone with access can open it and see the exact state. A passing project's machine is deleted. There's nothing to look at. The machines are named by hash, so even the dashboard is a list of anonymous builds. Not a list of teams.

A failing project's machine is a piece of feedback a team can open.

The run itself is unremarkable. Which is exactly the point. 164 submissions, 4 at a time, done in about 55 minutes while I made lunch, a median of 58 seconds per project. Every run in this post, including the ones I got wrong and had to repeat, cost a little over a dollar in usage. Imagine how long it would have taken to read 164 READMEs.

Every run in this post, on Fly's Cost Explorer: 2 days, $1.01 of usage.

What 164 projects look like when you build them all

The submissions came from one event, and I ran them all.

Of 164 submissions from a single hack, 113 built end to end: 69%.
33 installed their dependencies and then failed to compile or build.
8 would not install at all.
9 installed and had nothing to build, which is its own kind of answer.
1 repository was reachable on my first run and gone by my second, a day later.

I want to be careful about what "built" means here. It means the compiler accepted the code and the build script exited 0. It does not mean the project works, does what the README says, or would survive contact with a user. Building is the least a piece of software can do. It would be easy to read the 69% as projects being good. Of the 51 that did not build, 10 had either nothing to build or nothing to clone. The other 41, a quarter of the cohort, would not have built on any machine but their authors'. And at the judging table they looked identical to the ones that would, so every decision was made without the one fact that separates working software from a working demo.

The failures had shapes:

The most common was a contract that compiled cleanly with an application around it that didn't: the hard part worked, and the ordinary part (a TypeScript error, a missing build artifact, a package that never resolved) was what broke.
Second was the monorepo where one package failed and took the build with it.
Third, and rarest, was a repository that was a README and a diagram. Those are types, not teams. No project in this post is identified, and none will be.

Did they use the sponsor's tech or just the sponsor's logo?

Every sponsored hackathon has a second question underneath the first. Sponsors put up prizes to see their technology used, and the standard way to check is to read the README and look for the logo on the slide. Teams know this too.

Some of that question is machine-checkable, and some isn't. Checkable: does the repository contain a contract for the sponsor's platform at all? Is that contract the starter-kit example with the names changed? Does it use the platform's distinguishing feature or only the parts any database could do? Does it compile? In this cohort, 157 of 164 had a contract, exactly one was the example template with a fresh coat of paint, and 114 of the 157 compiled with the compiler version the contract itself declared. That last clause matters, and I'll come back to it.

Not checkable: whether the use was meaningful. A contract can declare a private input and do nothing interesting with it. The tool can tell a judge where to look. It cannot tell them what to conclude, and a tool that claimed otherwise would be doing the thing this whole post is against.

What the tool can't tell you and what I got wrong

Built is not the same as correct. "Tests passed" needs a caveat of its own: most teams started from a starter kit that came with tests already written, so a passing suite may be the starter's tests, untouched, and the tool can't yet tell those apart, which is why this post quotes no test-pass rate.

The tool answers one question, "Does it build?", and that's the lowest bar software can clear. It has no opinion on originality, difficulty, or whether the thing is any good. It can't see ambition either, so a team that attempted something hard and fell one compile error short lands on the same rung as a team that shipped a to-do list. Judges can see the difference. The tool is there to make sure they also see which one builds, which is exactly why it belongs beside a judging panel and not in place of one.

Then there's the mistake. The first version chose a compiler by date, the newest that existed when the repo was last touched. But a contract declares which language version it was written for, and a new compiler had shipped between the event and my run. 42 working contracts came back as failures, blamed on their authors, until the tool learned to read the declaration and install the compiler each contract asked for. The tool that exists to catch confident wrong answers produced one, and I only caught it because the error messages were all the same. It did it once more, after I thought it was finished: 6 build failures were my sandbox missing a compiler version the teams had pinned in their own scripts. All 6 build, and the numbers above are the corrected ones.

The compiler fix produced one more number worth knowing: compiled with today's release instead, a third of the working contracts no longer built. Every fast-moving platform does this to its early builders, and that's why you have to ask, "Does it work?" with the tools the team had, not the tools that shipped last week.

Tips before you run your next event

Run every submission before judging opens, and hand the judges the ladder. Not a score, a rung. The panel still decides what matters. They decide it knowing which projects build.
Give failing teams their machine. The tool saves it at the moment the build broke, so the team can open it, see the exact error, and fix it. Most hackathon teams have never received feedback that specific, and a saved machine costs nothing to keep.
Put "Does it build?" on the rubric. It was left off because it couldn't be filled in honestly for 60 teams in an afternoon. It can now, in about the time it takes the pizza to arrive.

Next, I'm taking my own advice: giving those 39 broken builds to an agent with a shell, a time limit, and one instruction. Make it build, and tell the team what was wrong. More on that in the next post 😉

The tool is on GitHub at github.com/laurenelee/hackjudge.
It's small, opinionated, and yours to run on your own submissions if you'd like!

Find me @lolocoding👩🏼‍💻

What it takes to build docs worth reading

Lauren Lee👩🏼‍💻 — Mon, 22 Jun 2026 15:24:45 +0000

Treating docs as a product

When documentation lives as an afterthought, it shows. Pages drift out of date, examples break quietly, and release notes scatter across a dozen places no one can find. The fix is not a weekend cleanup. It is a decision to treat docs the way you treat any product people depend on: someone owns it, it has standards, and it gets maintained on purpose.

That is the decision I made when the docs came to the Developer Relations team at the end of 2025. Not "let's tidy this up," but "this is ours now, and we are accountable for whether a developer can actually build from it."

The work, in the repository

The honest record of what a team does to a codebase lives in its git history, so that is where the story starts. Comparing the six months before the handoff to the six months since:

Before vs. Under DevRel:

Commits: 476 → 1,900+
Merged pull requests: 145 → 447
Unique contributors: 21 → 64

A repository that averaged fewer than 500 commits over half a year is now past 1,900 in the same span. The contributor count tripled, because we treated the docs as something the whole community could improve, not a walled garden. This is what a team that decided to do the work looks like when you measure it.

Our proudest metric is what was cut

In six months, we added roughly 339,000 lines and removed roughly 281,000.

That near balance is the point. A neglected docs site accumulates: dead pages, stale tutorials, examples that no longer compile, three slightly different explanations of the same concept. Adding more on top of that does not help anyone. So we cut nearly as much as we wrote.

We rebuilt the Hello World walkthrough from 1,300 lines down to about 300 without losing a thing. We consolidated scattered release notes into a single clean reference. A docs site is judged by what a developer can find and trust, not by how much sits on the shelf.

A library you can learn from

At the start of the year, the examples library had effectively one usable entry. Today, there is a progression a developer can climb, and every example demonstrates something specific about building on Midnight:

Alongside these sit a set of example contracts (a calculator, an election, a private guest list, a private reserve auction, token transfers) that did not exist before this year. Each one is built to be read, copied, and learned from. We retired the examples that taught nothing specific to Midnight, because an example that could belong to any chain is not teaching anyone why they are here.

Built to stay current

The hardest part of documentation is not writing it. It is keeping it true as the thing it describes keeps changing. A network moving as fast as Midnight breaks docs constantly if no one is watching.

So we built the watching into the process. There is now an automated review pipeline that checks every documentation change for quality and accuracy before a human ever looks at it. When a recent release changed import patterns across the codebase, the system flagged downstream content that would have become stale, and we held the update until it was corrected. That is the difference between docs you publish and docs you maintain.

AI tooling built for Compact

There is one more piece worth calling out, because it solves a problem unique to building here. Compact was not in the training data of the frontier AI models that developers reach for first. That meant the AI assistance developers now expect from every other ecosystem simply was not there for Midnight, and worse, a model would confidently invent Compact that does not work.

So we built the missing piece. Midnight Expert is a purpose-built knowledge base that teaches AI coding assistants to treat their Compact guesses as unreliable and verify against the real compiler and runtime tools before presenting anything to a developer. The same platform powers the automated documentation review described above, checking changes for accuracy before a human reviewer sees them.

If you are building on Midnight with an AI assistant in the loop, start there at midnightntwrk.expert.

The team behind it

This was a team effort in the truest sense. Jay Albert, our DevRel Engineer, Nick Stanford, our DevEx PM, and Idris Olubisi, our Developer Educator, built and rewrote example after example. Emmanuel Ameh, the newest member of our team and our Technical Writer, joined this year and took on the standards work end-to-end.

Nick also owns the release process that keeps every page in sync as the network changes—the continuous work that prevents documentation from going stale. And we brought in HackMamba to add concentrated firepower to align with the network launch deadline, with a substantial hand in the rebuild. None of the numbers above would have happened without these people.

Come build

I am not going to tell you the work is finished, because good documentation is never finished. It tracks a living network, and the network is still growing fast. What I will tell you is that the foundation is real now, the examples work, the tutorials are current, and a deeply engaged team is behind them every day.

If you have built on Midnight before, the docs are not the ones you remember. If you are new, you are arriving at a better starting line than the developers who came before you. Either way, the door is open.

Come build at docs.midnight.network, and tell us where we can do better.

Electric Capital report highlights growing momentum across the Midnight ecosystem

Lauren Lee👩🏼‍💻 — Fri, 19 Jun 2026 15:41:17 +0000

Electric Capital report highlights ecosystem growth

The Electric Capital developer report is an independent benchmark for tracking software engineering activity across the blockchain industry. The report aggregates open-source repository data and tracks unique contributors to provide an objective evaluation of ecosystem health and activity. This standardized methodology removes bias, allowing observers to compare developer engagement across different networks.

Data from the latest Electric Capital developer report highlights a major technical success for the Midnight ecosystem, showing a substantial acceleration in engineering activity in the months leading up to, and following, the network launch. The metrics outline a surge in contributors, putting Midnight on the map in the active developer ecosystem.

Midnight now appears in the same independent dataset that benchmarks Cardano, Solana, and Ethereum. As of the latest report, Electric Capital publicly tracks 1,028 repositories in the Midnight ecosystem. What makes that number worth citing is the method behind it: EC measures activity from open-source commit data the same way for every network, so the comparison rests on neutral ground rather than self-reported metrics.

Sustained activity backs this repository count. The developer community maintained an average of 150 monthly active developers throughout 2026. This consistent engagement confirms that active builders support these repositories, reflecting the collective efforts of the builders across the Midnight universe.

Check out all the Midnight ecosystem insights from the Electric Capital report.

Developer support fuels ecosystem growth

A steady stream of new developer tools, learning initiatives, and community programs directly powers the developer activity. New resources and protocol updates this month provide builders with enhanced capabilities for building and streamlining production.

Midnight Expert provides AI that runs Compact code

Frontier AI models have little training data for Compact, Midnight’s smart contract language. As a result, most AI assistants struggle to write Compact code, often filling the gaps with plausible-looking nonsense.

Midnight Expert is an open-source suite of Claude Code plugins built for the Midnight stack. Its Skills activate automatically based on context: setting up a local devnet triggers toolchain checks, version mismatch detection, diagnostics, and dependency fixes. Writing a contract hands off to a dedicated Compact agent that uses verified language patterns and a compile-test-validate pipeline, including ZK proof generation, to ensure generated code is accurate and hallucination-free.

In this Fireside Dev Hang, Lauren Lee and Aaron Bassett demo Midnight Expert live and unscripted, including generating a Midnight DApp from a single short prompt. Watch the video to see what Midnight Expert can do, then head to midnightntwrk.expert to get set up and start building on Midnight.

Offer files enable private atomic settlement

zSwap does private atomic swaps on layer one, and you can build on it on mainnet today. You post an offer, someone matches the opposing side, and it settles on-chain the moment the balances net to zero. Only the deltas are public. Addresses stay private, and there's no escrow risk.

The builder's unlock is the Offer File. Prove an offer locally, serialize it, and post it anywhere, a Discord channel, a Telegram group, or a shared Celestia namespace for public liquidity. Anyone can pull it down and match it, which means liquidity is shared across every Midnight project instead of each app fighting for its own.

EffectStream hands you live state over a simple RPC, so you never touch Celestia or Midnight indexing directly. And because the swap is a core protocol primitive rather than a contract you write and audit yourself, you can ship order books, RFQ DEXs, NFT marketplaces, and token launchpads without taking on that audit risk.

One current constraint to build around: Offer Files run with a one-hour expiry on the network today. The next hard fork extends that to two weeks. There's an order book template on GitHub to fork if you want a working starting point.

See the full walkthrough in the Fireside Hang with CTO Sebastian Guillemot.

Partner sprints accelerate application development

Partner sprints offer structured development initiatives that help teams build applications on the network. The previous sprint with 1AM recently concluded, resulting in custom-skinned wallets for the winning contributors: Spy, Violet_A, TomJohn, and HollandB. More information about these upskilling sprints can be found on the recent partner sprints blog.

Participants in the latest partner sprint with EddaLabs can compete for a bespoke engineering support session with ecosystem veterans. The top three participants will receive a dedicated technical session with EddaLabs engineers to review application architecture, evaluate design decisions, and audit Compact smart contracts. This is a great opportunity to learn directly from teams with years of Midnight experience. Participate now on Zealy.

Stay in the loop

The expansion of developer tooling, mainnet primitives, and ecosystem sprints provides multiple avenues for engineering engagement. Developers can access the repository templates, install the AI plugins, or participate in active community events to begin building privacy-preserving applications.

Subscribe to the Midnight developer newsletter to get monthly updates on everything going on across the Midnight developer community.

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.

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

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. 🌱

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.

Why We’re Shipping Curriculum Before It’s “Done” (And Why You Should Too)

Lauren Lee👩🏼‍💻 — Wed, 28 May 2025 11:14:43 +0000

At Midnight, we’re building a new kind of blockchain. One focused on data protection, developer experience, and real-world impact.

And as we grow our developer ecosystem, we’re doing something many teams are afraid to do.

We’re releasing our developer curriculum before it’s “done.”

Not because we’re lazy.

Because we believe that early feedback, real-world usage, and community collaboration will lead us to a stronger, more usable learning experience.

The Trap of Waiting for Perfect

Too many developer education teams hold back content until it’s “finished.” Polished. Market-ready.

But the truth is, good curriculum is never truly finished.

As someone who’s been both a high school English teacher and a DevRel leader, I’ve seen firsthand that the best learning doesn’t come from a perfect script. It comes from iteration. From shipping. From engaging with students/learners while the material is still taking shape.

So we’re taking a different approach.

We're shipping early and learning in the open. We're publishing usable content early, inviting feedback, and improving it alongside the developers who use it.

Introducing the Midnight Developer Academy

Recently, we quietly launched Midnight Developer Academy: our educational hub for developers who want to become experts in Zero-Knowledge Proofs and learn how to build DApps with data protection at the core.

Here’s what’s live now:

👩‍🎓 The first 3 of 8 core modules
✍️ Written, direct, and focused on hands-on learning
⚡ Designed for usability, not perfection

And here’s what’s on the roadmap/coming soon:

🎥 Video content and interactive labs
🌍 University partnerships and blockchain society integrations
💻 Self-paced learning on major online platforms
🧑‍🏫 Cohort-based workshops and live office hours
🤝 Partner-contributed modules on advanced use cases

This isn’t about checking a box. It’s about delivering real value now and letting our developers help shape what comes next.

Why I Love This Approach

By shipping early, we’re already seeing wins:

Developers are completing the first modules and asking for more
We’re collecting specific, actionable feedback to guide the next releases
Our community feels involved, not sidelined

This is our bet:

Progress beats perfection
Trust is built through transparency
Gatekeeping (is toxic and) slows learning

If you’re in DevRel, developer education, documentation, or product enablement, ask yourself:

👉 What’s the cost of waiting until it’s “done”?

👉 What opportunities are you missing while you polish?

👉 Could your community be helping you right now?

Build With, Not Just For

We believe that building with developers, not just for them, is how ecosystems thrive.

That means opening the door earlier. Listening harder. And iterating out in the open.

So here’s our call to action to the Midnight community:

💥 Dive into the first three modules

📝 Tell us what’s missing

📣 Help shape what comes next

We’re not waiting for perfect.

We’re learning, shipping, and growing together!

DevRel in Web3: Building Systems that Scale While the Ecosystem is Still Taking Shape

Lauren Lee👩🏼‍💻 — Wed, 23 Apr 2025 09:09:15 +0000

“Don’t optimize for today. Build the scaffolding for scale.”

Intro

The pace of web3 is dizzying. Protocols evolve weekly. Docs lag behind releases. Tooling is in flux. Community sentiment shifts with the market. For Developer Relations teams, that means operating in a state of constant motion and navigating uncertainty while trying to create structure and momentum.

On our DevRel team at Midnight, we’re not just reacting, we're designing systems that can outlast us. This blog post is a look inside how we're thinking about DevRel in an emerging ecosystem, and what it takes to build not just community, but infrastructure for community.

From tasks to systems: The DevRel Flywheel

The traditional DevRel playbook doesn’t hold up when the ground keeps shifting. That’s why I’ve shifted from thinking in terms of tasks, such as “write this guide” and “host that hackathon,” to thinking in terms of systems.

Enter the DevRel Flywheel. A concept originated by Matthew Revell that we’ve adapted for web3. Here’s how it works at Midnight:

Developer activity sparks early traction and interest
Community engagement amplifies that momentum
Trust and support build confidence and
Ecosystem visibility brings new builders and use cases
New projects fuel more developer activity

community > credibility > projects" width="800" height="800">

The more we feed the flywheel with education, support, and visibility, the less we need to push manually. Our role becomes about momentum maintenance, not manual motion.

Mapping the developer journey at Midnight

To make the flywheel spin faster, we have mapped the journey a developer typically takes within our ecosystem. This helps us design the right interventions at each stage, and it aligns with Phil Leggetter's AAARRRP framework (Awareness, Acquisition, Activation, Retention, Referral, Revenue, Product) used across DevRel and growth teams.

Stage	Midnight Journey	AAARRRP Phase
First Touch	Social, talks, blogs, conferences	Awareness + Acquisition
Education	Tutorials, Discord livestreams, ZK workshops	Activation
Documentation	Quickstarts, use-case driven docs, APIs + SDKs	Retention
Hackathon	Build events, project feedback, prizes	Retention + Referral
Ecosystem Contributor	PRs, mentoring, writing, core feedback	Referral + Product Growth

This journey acts as both a map and a compass. It gives us clarity on:

Where we’re losing developers
Where we can accelerate outcomes
How to tailor support, education, and incentives at each stage

We don’t just hope developers stick around. We design the journey so they thrive at every stage.

education > docs > hackathon > ecosystem contributor" width="800" height="800">

What we’re learning (and unlearning)

We’re early in this journey, and we’re experimenting constantly. Here are a few unexpected lessons from our DevRel systems design so far:

Education should drive contribution, not just consumption
Docs should meet developers by intent, not by section
Example apps should collect feedback, not just showcase use
Support should default to public and persistent, not private DMs
Incentives should build reputation, not just distribute prizes

Not everything from web2 works in web3. And sometimes, what didn’t work there is what works here.

Rethinking hackathons in web3

I used to be skeptical of hackathons. I worried they were just prize-driven traffic spikes with no long-tail return. But at Midnight? They’re proving to be launchpads.

We’re seeing multiple hackathon teams/projects go on to receive grants, and we’re now actively investing in the winners' journeys. This doesn’t mean we won’t keep evolving the format (we will), but it’s changed how I think about incentives, retention, and early-stage builder support across the board.

A system that feeds itself

What we’re building now will shape the culture and sustainability of our developer community for years to come. If we only optimize for today (fix this doc, answer that question), we’ll burn out before we ever get to scale.

So instead, we’re asking:

How can we structure support so that our community helps itself?
How can we collect feedback so that every new tutorial gets smarter?
How can we build with devs, not just for them?

An invitation to fellow web3 DevRel builders

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

What’s working for you? What isn’t? What does your flywheel look like?

Let’s swap notes. Let’s compare scars. Let’s collaboratively build systems that make it easier for the next wave of builders to build what matters!

-- ✨👩🏼‍💻 lolocoding

DEV Community: Lauren Lee👩🏼‍💻

33 broken builds, one agent on each disposable computer. The hard part was deciding what counts as fixed.

First, give it to a robot

What the agent was given

What 33 broken builds look like when you hand them to an agent

Two models, same machines

What the harness got wrong, in order

What this doesn't tell you

The changes I'd make before your next hackathon

164 disposable computers, one judging afternoon, and a question nobody had time to ask

Does it build?

Do the math on a judging afternoon

What changed is the price of a computer

What the tool refuses to do

What 164 projects look like when you build them all

Did they use the sponsor's tech or just the sponsor's logo?

What the tool can't tell you and what I got wrong

Tips before you run your next event

What it takes to build docs worth reading

Treating docs as a product

The work, in the repository

Our proudest metric is what was cut

A library you can learn from

Built to stay current

AI tooling built for Compact

The team behind it

Come build

Electric Capital report highlights growing momentum across the Midnight ecosystem

Electric Capital report highlights ecosystem growth

Developer support fuels ecosystem growth

Midnight Expert provides AI that runs Compact code

Offer files enable private atomic settlement

Partner sprints accelerate application development

Stay in the loop

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

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

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

How the Community Board Works

Why this matters

Say Hello to example-counter and example-bboard

From ZIP Files to GitHub: Opening the Gates

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

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