July 2026

Ethereum Flakes

By Christopher Robison

Nix

Nix is a programming language (Nix), package management system (referencing nixpkgs), and operating system (NixOS) all at once. The term Nix can be used to reference any of these components individually or the sum of their parts collectively (Nix). This is often awkward for newcomers to understand, much in the same way it is confusing how bitcoin is simultaneously a protocol, software client, and cryptocurrency.

Overview

The Nix language is not a general-purpose runtime language used to write applications. Instead it is an architectural language used to describe how systems are constructed. In other words, Nix defines environments rather than programs. Its purpose is to formalize how software is assembled so that, once a configuration works, it can be reproduced across different machines.

The nixpkgs repository is, itself, one massive collection of Nix expressions (written in Nix) containing more than 120,000 packages. Each expression describes how its software is built, including all dependencies. It is by far the largest (public) monorepo in the world, and it is primarily used to configure and build NixOS environments.

The NixOS operating system lives inside nixpkgs. Bootstrapped from a trusted seed binary and toolchain in order to run its first Nix command, modules are recursively imported from nixpkgs until the entire operating system is assembled solely using Nix expressions. The OS can then be further modified by updating its configuration.nix file.

Diagram of Nix's self-referential build structure — The self-referential nature of nix is what has led to it becoming not only the largest monorepo on the open web, but one that remains remarkably stable.

Configuration.nix

The most relevant Nix expression that the average NixOS user encounters is the configuration.nix file. This file describes nearly everything necessary to build a system, including the desktop environment, settings, services, modules, and installed packages. If you were to copy your config file and share it with a friend, it would build them an identical machine.

The most distinctive attribute of the Nix language and package manager is that it is declarative. To install a new piece of software on your system, you simply open the config file and add the name of the desired module to its relevant class, like: packages = with pkgs; [thunderbird]. The system then references nixpkgs to create an isolated build graph to eliminate conflicts with other packages already on your machine. The package simply works.

Example of adding a package to a NixOS configuration file — Package names are often simple, and adding them to the list of pkgs is all that's required for installation.

Flakes

For any packages not already added to nixpkgs, it is still possible to install "outside" software using a type of experimental Nix expression, called flakes. A flake.nix file requires more detailed inputs than the average config declaration, but it permits a user to deterministically build any software with as much granularity as desired, to the point of locking in an exact version pinned to a precise git commit.

Radical Stability

At its core, Nix is a framework to reproducibly build complex infrastructure deterministically. Given a fixed set of inputs, it will always produce the same output. Today it is applied in relatively traditional ways by sysadmins (see: CERN, EU Space Agency), devops teams (Google, Shopify, Mozilla), and homelab enthusiasts (example). However, Nix has the potential to transform computing altogether by creating a paradigm of radical stability.

The Problem: Computational Friction

When it comes to software, stability is sovereignty. In conjunction with the principles of CROPS, stability is the foundation required to build digital sanctuaries where inhabitants are shielded from the shifting sands of fragile dependency trees, hyper-extractive big tech, and political capture.

These shifting sands are severely consequential. They can occur when digital supply chains are attacked, companies change business models, and political agencies restrict internet traffic. In each case, infrastructure is captured, modified, and exploited to asymmetrically impact millions of innocent people. Non-deterministic systems are an insidious type of "computational friction" which can be remedied by Nix much in the same way that bitcoin originally rallied to "reduce financial friction."

Diagram of fragile infrastructure controlled by special interests — When infrastructure is vulnerable, special interests able able to build commercial or public services that feel user friendly at first, but which can be turned off or degraded over time as the owners' interests and users' diverge.

The Solution: Slay the Imperative Dragon

When bitcoin launched, central banks were the proverbial dragon to be slayed. Today, it is non-deterministic, imperative systems. Windows, MacOS, Android, and nearly all Linux distributions are configured imperatively. This means they must execute specific, sequential commands in order to manage resources and perform tasks. Contrast this with declarative systems, which treat the entire configuration as a single function of inputs and outputs.

Diagram contrasting imperative sequential commands with declarative configuration

Sequential commands are not fundamentally problematic on their own. However, at scale, they become incredibly difficult to maintain. Thus, only a "high priestly class" of systems engineers at resource-rich enterprises are able to build large infrastructural products, like G-Suite or Instagram, that feel semi-stable to the average consumer. Of course, in practice, they are anything but stable, as they operate at the whim of private entities.

Digital sovereignty activists criticize these enterprises for accumulating disproportionate amounts of power and recommend that people return to free and open source software as a form of protest. The poignant irony is that embracing imperative systems — even if they are open source — only reinforces the problem. Enterprises will always be able to maintain a deeper stack of sequential commands.

Nix expressions offer a stable alternative. If a configuration can be built once, anyone else can declare the same expression in order to run it locally on their own machine. This permits open source software with the ability to compound in complexity as new declarations are slowly added to a config over time. There is no need for centralized authority or coordination. FOSS suddenly becomes antifragile under a single, shared build language.

Furthermore, Nix expressions reduce the barrier to entry for both FOSS adoption and distribution. Fully-defined systems can, in principle, be shared as casually as a text message is sent and run instantly. This ad hoc, yet stable, distribution model begins to rival enterprise-controlled infrastructure in a way imperative systems never could.

Diagram of configuration drift in imperative infrastructure over time — It is normal for imperative infrastructure to experience "configuration drift," which requires continuous refactors, rebuilds, and resets. Enterprises overcome this limitation with superior capital and labor, while declarative systems achieve the same with superior functionality. The latter may indeed be more efficient over the long term.

Generational Infrastructure

If declarative Nix expressions can compound in complexity without impeding stability or distribution, then independent infrastructure can be built and maintained to last for generations. And not just by highly skilled communities of developers, but by families with even a modest amount of technical familiarity (assuming a meaningful level of abstraction & UX design). Nix makes sovereign self-hosting tenable for everyone.

With the right build recipe, a family could:

Establish a secure, private network across everyone's personal computer
Set up a home server on the network to store all core, canonical family data
Add smart devices, like biometric wearables, to reference stored data, e.g. family health records
Run local LLM models as a friendly interface to query all family data
Use the local LLM to generatively build bespoke family-specific apps, like a health tracker
Share the generated app with a extended family member, who runs a similar build recipe for their own nuclear family and has a genetically shared health profile
Pass this build down to their children

This infrastructure could be extended, replicated, and partitioned to evolve any way that might best serve future generations. And the best part is: there are no platforms or 3rd party operators involved. All commercial dependencies could feasibly be eliminated, or at least properly sequestered.

Illustration of a family homestead as an analogy for generational computing infrastructure — Families design homesteads with various forms of planned and emergent complexity to serve their kin for generations. The same could be done with computers using functional instruction sets.

Distributed Expressions

Naturally, generational infrastructure can be owned and operated by any group, community, or subculture; not just families. Ethereum, in particular, is ripe to implement Nix expressions at scale. It is a multipurpose, unstoppable, infinite machine, intended to function as the world computer for current and future generations. Complex build systems, which support Ethereum, could be readily distributed as reproducible Nix flakes as a means of improving the integrity of the protocol, safety of dapps, and sovereignty of DAOs.

DVT

Distributed validator technology (DVT) is a system of running multiple nodes simultaneously to secure the stake of a single validator. If one node goes offline or fails for any reason, the other machines will continue to attest using a threshold signature scheme. DVT additionally creates an opportunity to improve client diversity for the network, as validators are able to run different clients on each node in their cluster. DVT thus preserves the integrity of Ethereum, which is, itself, generational infrastructure.

Although straightforward in principle, DVT is notoriously complex to run in practice. Furthermore, if it is not configured correctly, the validator risks slashing penalties. There are presently two proposals to simplify DVT and make it more accessible: (i) enshrine DVT natively into the protocol and/or (ii) distribute DVT as a deterministically reproducible package. The latter is obviously an appropriate fit for Nix.

Existing Nix flakes are available, which permit a fleet of machines to be controlled by a single administrator over a secure, private intranet. Instead of configuring each node separately, the admin can simply declare the build state of the entire fleet all at once. This construction is analogous to how BIP-32 standardized the hierarchical deterministic (HD) wallet, which allow a single private key to control multiple wallet accounts. Nix enables HD computing: a single admin controls multiple machines. Instead of one private key, it uses a single build system. Configured correctly once, such a DVT expression could be replicated on anyone's machine.

Dapp Interfaces

Ethereum smart contracts are pure generational infrastructure. Their logic and state will persist indefinitely onchain for as long as the network is live. This is especially true for governance-free protocols, like Liquity. Unfortunately, dapp interfaces do not possess the same attribute.

A truly self-sovereign interface requires a local (i) GUI, (ii) RPC endpoint, and (iii) transaction signer. Attempts have been made over the years. However, they are all generally designed in the context of browsers, which are highly complicated pieces of software. Browsers aim to function as sandboxes that safely execute code published and run by anyone in the world on any machine. Effectively, they wish to be the universal operating system.

Three historical attempts at self-sovereign dapp browsers: Mist, Dappnet, and browser extension wallets — Left: the Ethereum Foundation's Mist browser was built with electron. Middle: Dappnet ran in chromium. Right: the industry standard is to now run wallets as browser extensions to connect to web apps.

Consequently, the browser is inherently required to function as one massive "shifting sand." Its lack of specialization demands it constantly be rebuilt to accommodate new uses. This type of execution environment dramatically exceeds the scope necessary to run basic dapp interfaces. In fact, it actually introduces a variety of vulnerabilities that could be exploited to harm dapp users. Interfaces could, instead, simply be run as isolated, local flakes.

A flake would ensure all dependencies are installed and configured correctly, including services, such as RPC endpoints, which could be pointed at a local full or lite node client. A single command would ensure immediate access to the frontend is run inside a secure, isolated environment, like a local WebView instance:

nix run git#https://github.com/liquity/frontend/#frontend_name

A more Ethereum-native use of ENS domains could also be implored to simplify the command:

nix run ens#liquity-eth

Users could archive dapp flakes locally to ensure they are always in possession of a trustworthy interface. As project developers push new frontend changes, users could better control when they opt-in and to what version. Flakes could then be easily shared among peers and, of course, passed down to future generations.

DAO Portals

Most dapp interfaces are single player. By contrast, DAOs are frequently multiplayer and require additional tools for social coordination, such as token-gated group chat, community forums, snapshot voting, and project management. Instead of rendering the UI in a mostly static WebView, a more sophisticated Nix expression could be written to assemble a microVM.

Within the microVM, an entire suite of p2p tools and services would be assembled inside a community intranet. Users could open their portal and begin participating in all facets of the DAO immediately. For all intents and purposes, this microVM would become the de facto DAO_OS, a one-stop-shop for everyone to do everything. DAO engagement would no longer be fragmented across a disparate landscape of 3rd-party platforms, but consolidated under a single build system.

The DAO flake, itself, would be pinned to an ENS record and updated with a community vote. If, for example, a privacy-conscious community wanted to ensure all members of the portal were pseudonymous by default, they would submit a proposal to add the tor package to their config. Anyone who excluded the package would be unable to participate; everyone's systems must be identical. It is HD computing, where the fleet admin is expressed in the ENS record.

The recursive nature of a DAO portal, pinned to a public record, updated by a DAO vote would allow the portal to perpetually evolve to meet the local needs of the community. The use of generative AI to build bespoke applications and synthesize community decision making would only further accelerate this process. The outcome would produce not just generational infrastructure, but generational culture.

Conclusion

Humans deserve to live in peace. Yet we are encumbered with hyperobjective uncertainty everywhere, especially online. Few kernels of digital sovereignty exist. And although Ethereum is one, it sits at the top of our technological stack at the protocol layer. We need to reach further down towards the base to instigate real change. Nix can achieve this, but its true potential needs to be nurtured. The opportunities for Nix to bolster Ethereum infrastructure is itself an opportunity for Ethereum to elevate the status of Nix as a tool for all computing. If Ethereum adopts Nix, it may catalyze a Cambrian explosion for sovereign infrastructure, built to last for generations.