Build System
Documents the Nix-based build system and the modular architecture of dapp, seth, and hevm tools.
What this file does
Documents the Nix-based build system and the modular architecture of dapp, seth, and hevm tools.
When to use it
- Understanding how dapptools are built with Nix
- Learning the hevm interpreter and fetcher architecture
- Replicating the script dispatch pattern for CLI tools
- Designing pure EVM semantics with pluggable interpreters
Assumes this stack
Build System
All tools in this directory are built with nix, a declarative package manager
which gives a secure and predictable bundling of dependencies.
They are defined as attributes in the ./overlay.nix file,
which in turn imports the default.nix file of each tool.
The dependencies of each tool is set as buildInputs in the default.nix file.
dapp & seth
dapp and seth are similarly structured as a collection of short scripts, mostly written in bash.
The main entrypoint for any invocation of seth or dapp is a dispatch script,
./src/seth/libexec/seth/seth and ./src/dapp/libexec/dapp/dapp respectively, which parses any
flags given, setting their values to the appropriate environment variable, and dispatches to the
appropriate subcommand.
hevm
The core evm semnatics in hevm can be found in EVM.hs. EVM state is contained in the VM record,
and the exec1 function executes a single opcode inside the monad type EVM a = State VM a.
The core semantics are pure, and should information from the outside world be required to continue
execution (rpc queries, smt queires, user input), execution will halt, and the result field of the
VM will be an instance of VMFailure (Query _).
Multiple steps of EVM execution are orchestrated via interpreters for a meta language. Programs in
the meta language are called Steppers. The instructions in the meta language can be found in
Stepper.hs.
There are many different interpreters with different features, e.g. a concrete interpreter, a symbolic interpreter, an interpreter that collects coverage information, a debug interpreter that can accept user input. Interpreters can handle Queries in different ways, for example in the symbolic inerpreter, both sides of a branch point will be explored, while in the symbolic debug interpreter, user input will be requested to determine which side of the branch point will be taken.
Interpreters are parameterized by a Fetcher that can handle rpc and smt queries, and can be
instantiated with fetchers that could have different fetching strategies (e.g. caching).
Interpreters execute Steppers and use their Fetcher to handle any Queries that need to be resolved.
This architecure is very modular and pluggable, and allows the core semantics to be shared between different interpreters, as well as the reuse of steppers between different interpreters, making it easy to e.g. replay a failed test in the debug interpreter, or to share the same test execution strategy between concrete and symbolic interpreters.
graph LR
subgraph meta-language
A[Stepper]
end
subgraph interpreters
A --> B[Concrete]
A --> C[Symbolic]
A --> D[Coverage]
A --> E[Debug]
end
subgraph fetchers
F[Fetch.hs]
B --> F
C --> F
D --> F
E --> F
end
subgraph EVM Semantics
G[EVM.hs]
B --> G
C --> G
D --> G
E --> G
end
What's inside
3 tool descriptions, 1 Mermaid diagram, build inputs and overlay structure
Change this for your project
- Replace
./overlay.nixwith your own Nix overlay path - Replace
./src/seth/libexec/seth/sethwith your dispatch script path - Replace
./src/dapp/libexec/dapp/dappwith your dispatch script path
Where it goes
Save in docs/ or the repository root. Gives agents and new contributors a map of the codebase.
Worth borrowing
- Separating core semantics from interpreters and fetchers for modularity
- Using a dispatch script to parse flags and route to subcommands
Related Documents
PCB Design Sources for Industry-Scale Testing
Lists GitHub repos and communities where you can download real PCB designs for testing optimization at scale.
Design Document: BharatSeva AI
Describes a 10-agent AWS system that helps India's informal workers access government schemes via voice-first, serverless architecture.
OpenClaw Enterprise Transformation Plan
Transforms a single-user AI agent into a dual-mode platform supporting both viral open-source and Fortune 500 enterprise deployments through phased security, IAM, audit, multi-tenancy, and Kubernetes features.
Qwen Image and Edit: Open-sourcing and Local GGUF Generations with Lightning
Documents the Qwen-Image and Qwen-Image-Edit models, covering architecture, training, benchmarks, ComfyUI setup, and prompting techniques for local GGUF deployment.