Minimal Executable Program (MEP)

• Minimal Executable Program (MEP) is a succinct artifact that includes only the essential components needed to compile, run, and validate specific target properties.
• It applies across various domains—from consensus rule specifications and GPU kernel optimization to formal verification—ensuring clear dependency boundaries and reproducible behavior.
• MEPs emphasize minimal sufficiency and explicit execution boundaries, enabling isolated testing, performance tuning, and rigorous validation of target behaviors.

Minimal Executable Program (MEP) is a polysemous term used in several distinct research settings to denote the smallest executable artifact that still preserves a target property under direct observation, measurement, or proof. In the literature represented here, MEP can mean a compact, implementation-independent executable specification of consensus rules; a standalone harness that makes an extracted GPU kernel compilable, runnable, measurable, and correctness-checkable outside a full application; a minimal ELF binary whose machine-code input/output behavior is formally specified and proved; or a byte-minimized standalone Linux executable that remains functionally complete for its declared purpose (Sharp, 19 Sep 2025, Chu et al., 15 Dec 2025, Carneiro, 2019, O'Leary et al., 2023). A closely related notion, the Minimal Executable Proof, uses executable witnesses and structural validators to connect a contract to concrete implementations and traceability evidence (Kasselman, 27 May 2026). Across these usages, the common idea is not merely small size, but minimal sufficiency: the artifact includes only what is necessary to compile, execute, validate, and reason about the target behavior.

1. Terminological scope and definitional variants

The term MEP does not name a single canonical formalism across the cited works. Instead, each domain fixes its own operational notion of minimality and executability.

In the Hornet work on Bitcoin consensus, a “minimal, executable specification” is a compact, declarative set of pure, composable validation rules that, when executed, completely determine Bitcoin’s consensus behavior without hidden state, side effects, or reliance on legacy client internals (Sharp, 19 Sep 2025). Mapped to the notion of an MEP, this formulation emphasizes compactness, unambiguous rules, deterministic semantics, controlled side effects, and implementation neutrality.

In GPU kernel optimization, an MEP is a minimal, standalone program containing an extracted hotspot kernel together with the harness, reconstructed interface, input generators, dependency stubs or mocks, correctness validator, build settings, and runtime configuration needed to compile, run, time, and validate the kernel in isolation (Chu et al., 15 Dec 2025). Here, minimality is defined by exclusion of full-application dependencies, while executability is tied to stable measurement and functional equivalence checking.

In the Metamath Zero framework, an MEP is a small, self-contained ELF/x86-64 binary together with a minimal formal specification and proof of its input/output behavior, verified in a simple logic and with a proof checker intentionally limited to the smallest set of features necessary (Carneiro, 2019). Minimality applies simultaneously to the executable, the logic, the specification, and the checker.

In Ribbit, the paper’s 7 KB R4RS-compliant REPL qualifies as an MEP because it is a single Linux ELF binary with no external dependencies, yet still implements a complete R4RS REPL and satisfies R4RS conformance testing (O'Leary et al., 2023). In this usage, the decisive criterion is byte-minimized functional completeness.

The contract-traceability paper distinguishes Minimal Executable Program from Minimal Executable Proof. In that setting, the program side is the smallest multi-language set of canonical “Hello, world!” implementations needed to instantiate a proof for contract C01, while the proof side is the compact, falsifiable artifact that links the contract to implementations, witnesses, validators, a DAG, traceability chains, a readiness gate, and an evidence matrix (Kasselman, 27 May 2026).

A concise comparison is given below.

Context	What counts as the MEP	Primary minimality criterion
Bitcoin consensus	Ordered pure rulesets and DSL rules	One invariant per rule; explicit context; no hidden state
GPU optimization	Standalone kernel harness	No full-source dependencies; isolated measurement and FE
MM0 verification	ELF binary plus proof/spec	Minimal logic, checker, and executable semantics
Ribbit Scheme	Single Linux ELF REPL	Smallest byte footprint preserving R4RS REPL functionality
Contract traceability	Smallest multi-language program set	Minimal programs sufficient to witness contract C01

This suggests that “minimal” is always domain-relative. A plausible implication is that MEP is best understood as a methodological pattern rather than a single artifact class.

2. Shared structural principles

Despite the divergence in application domains, the cited works converge on a recognizable structural core.

First, MEPs are deliberately scoped. Hornet expresses each consensus invariant as a single rule and organizes rules into small, ordered rulesets, with consensus logic strictly separated from data structures, networking, and application concerns (Sharp, 19 Sep 2025). The GPU framework includes only what is necessary for compilation, execution, measurement, and validation of the extracted kernel (Chu et al., 15 Dec 2025). MM0 formalizes only the semantics required by the target executable, including only the Linux syscalls necessary for simple read/write operations and exit (Carneiro, 2019). Ribbit chooses R4RS specifically to keep the system small while remaining practical, and omits features such as hygienic macros and floating-point arithmetic that would inflate size (O'Leary et al., 2023).

Second, MEPs make the execution boundary explicit. In Hornet, rules operate on immutable inputs and explicit validation contexts; state access is via minimal view interfaces such as consensus::HeaderAncestryView and AncestorTimestampsView (Sharp, 19 Sep 2025). In GPU optimization, the interface is reconstructed precisely, including function signatures, parameter types, memory layouts, and strides, and the harness controls build settings, runtime configuration, and timing (Chu et al., 15 Dec 2025). In MM0, the machine state is formalized as Config = { ([RIP](https://www.emergentmind.com/topics/restricted-isometry-property-rip), regs, flags, mem) | RIP ∈ u64, regs: u4 → u64, flags ∈ u64, mem: u64 → (Prot × u8) }, and IO is externalized as streams in KernelState = List u8 × List u8 × Config (Carneiro, 2019).

Third, MEPs privilege determinism or tightly controlled nondeterminism. Hornet’s rules are pure and deterministic on immutable inputs, with identical inputs yielding identical outputs (Sharp, 19 Sep 2025). The GPU framework seeks stable, repeatable performance feedback through repeated runs, trimmed means, and FE gating (Chu et al., 15 Dec 2025). MM0 allows nondeterminism only where hardware manuals leave behavior unspecified or where the model abstracts away details outside user mode (Carneiro, 2019). The contract-traceability witnesses produce categorical PASS, SKIP, and FAIL outcomes under declared assumptions about toolchain availability and a standard POSIX-style runner with UTF-8 pipes (Kasselman, 27 May 2026).

Fourth, MEPs are audit-oriented. Hornet aims at theorem proving, model checking, differential testing, and AI-driven adversarial testing (Sharp, 19 Sep 2025). The GPU framework uses correctness validators and Automatic Error Repair to keep optimization search bounded by executable evidence (Chu et al., 15 Dec 2025). MM0 reduces the trusted computing base to the verifier binary and the correctness theorem statement (Carneiro, 2019). The traceability artifact makes claims falsifiable by linking them to named files, validators, and witness outputs (Kasselman, 27 May 2026).

A common misconception is that an MEP is simply a toy or microbenchmark. The literature does not support that reduction. In these papers, minimality is used to sharpen semantic control, improve auditability, reduce trusted surface area, or decouple expensive integration contexts from the executable object of interest.

3. Executable specifications as MEPs

In consensus systems, the MEP idea is used to recast “the code is the spec” into a smaller and more analyzable executable object. Hornet Node and the Hornet DSL argue that Bitcoin’s consensus rules can be encoded as a compact, executable, declarative C++ specification and a purpose-built DSL, with header, transaction, and block validation rules expressed in fewer than 50 lines of executable C++ rulesets, each rule handling exactly one invariant (Sharp, 19 Sep 2025).

The paper’s concrete examples show how minimality is operationalized. ValidateProofOfWork is encoded as a single comparison between header.ComputeHash() and header.GetCompactTarget().Expand(), returning InvalidProofOfWork on violation. ValidateMedianTimePast checks that header.GetTimestamp() > view.MedianTimePast(), where MTP is defined operationally as the median of the prior 11 block timestamps. ValidateTimestampCurrent uses a fixed tolerance kTimestampTolerance = 2*60*60, enforcing that a header timestamp must not exceed network-adjusted time plus two hours. Contextual block validation is similarly structured through require and @bip(...) annotations in the DSL, making activation-dependent rules explicit rather than embedding deployment logic in general-purpose code (Sharp, 19 Sep 2025).

This architecture treats the executable specification itself as the minimally sufficient program. Consensus rules are pure; state access is narrowed to view interfaces; no global mutable state or concurrency enters consensus logic; and the DSL constrains syntax and semantics so that theorem provers and LLMs can analyze the rulesets (Sharp, 19 Sep 2025). The client validates mainnet headers in under 3 seconds and validates all blocks to tip “in a few hours on a single thread,” which the authors use to argue that minimality does not preclude practical execution (Sharp, 19 Sep 2025).

This suggests a specific research role for MEPs: not merely shrinking software, but isolating the consensus-critical semantic kernel so that implementation detail no longer functions as an unreviewable specification.

4. Isolated optimization harnesses and kernel-centric MEPs

In high-performance computing, the MEP becomes an optimization harness designed to break the dependency between kernel tuning and full-application builds. The GPU paper formalizes the MEP around an extracted hotspot kernel $K$ and states explicit execution-time and data-size constraints:

$$\left\{ \begin{aligned} T_{\text{ker}} &\ge T_{\text{min}},\ T_{\text{overall}} &\le T_{\text{max}}. \end{aligned} \right.$$

and

$S_{\text{data}} \le S_{\text{max}}.$

The MEP contains the kernel, a driver or harness, reconstructed interfaces, input data generators, dependency stubs or mocks, a correctness oracle or validator for FE, build scripts, toolchain settings, and runtime configurations (Chu et al., 15 Dec 2025). The driver allocates memory, prepares inputs, configures execution parameters, launches the kernel, retrieves outputs, reports timings, and reduces timing noise through warmup runs and repeated measurements.

The optimization loop is defined over this executable object rather than the original application. Candidate kernels are generated, built in the MEP, repaired via Automatic Error Repair when compile, link, runtime, or correctness errors occur, and accepted only if they pass FE relative to the current baseline. The paper defines trimmed-mean timing as

$$\overline{T_{\text{ker}}^{(d,n)}} = \frac{\displaystyle \sum_{i=k+1}^{R-k} T_{(i)}^{(d,n)}}{R - 2k}, \quad \text{with } R > 2k,$$

the feasible set as

$$\mathcal{C}^{(d)} = \left\{ K^{(d,n)} \;\middle|\; 1 \le n \le N,\; \text{FE}\big(K^{(d,n)}, K^{(d)}\big) \right\},$$

and selection as

$$n^\star = \arg\min_{1 \le n \le N,\; K^{(d,n)} \in \mathcal{C}^{(d)}} \overline{T_{\text{ker}}^{(d,n)}}, \qquad K^{(d+1)} = K^{(d,n^\star)}.$$

Speedup is defined as

$$\text{Speedup} = \frac{t_{\text{baseline}}}{t_{\text{optimized}}}.$$

The empirical results reported for the MEP-based framework are average integrated speedups of 5.05× on PolyBench for NVIDIA, 7.77× on PolyBench for DCU, 1.77× on AMD APP SDK, and 1.25× on three large-scale hotspot kernels, with consistent outperformance relative to Direct LLM Optimization (Chu et al., 15 Dec 2025). The framework is evaluated on NVIDIA GPUs and the Haiguang Deep Computing Unit platform using CUDA and HIP toolchains, and reintegrates optimized variants into the original applications for validation (Chu et al., 15 Dec 2025).

The methodological significance is that the MEP serves as a controlled experimental substrate. A plausible implication is that, in optimization settings, “minimal executable” means an executable whose performance signal is representative enough to guide search, yet cheap enough to permit many compile–run–repair cycles.

5. Formal verification, machine-code semantics, and proof-carrying minimal executables

The MM0 work presents an especially strict version of the MEP idea, in which the executable and its formal semantics are co-minimized. The target object is a small, self-contained ELF/x86-64 binary, and the proof framework formalizes only what is needed to specify and prove its input/output behavior: a simple first-order logic equivalent to Peano Arithmetic, a custom verification language and proof checker, a partial x86-64 semantics for common user-mode integer instructions, and Linux syscall models sufficient for simple IO (Carneiro, 2019).

The executable semantics are defined over a machine state with registers, flags, and protected memory; loads and stores consult Prot bits; unsupported instructions or protection-faulting steps are disallowed. IO is modeled by extending state with abstract stdin and stdout streams rather than embedding external interaction in memory. The ELF model is likewise restricted to a single PT_LOAD segment, no linking or relocation, no section headers, a defined entry point, and a small stack allocation containing argv and argc (Carneiro, 2019).

A concrete MEP example in the paper is a minimal program that writes "Hello, world\n" to stdout and exits with status 0 via write and exit syscalls. The desired correctness theorem states the existence of a finite execution prefix in which the output stream is extended by the message bytes and the process terminates, with no further steps from the terminal state (Carneiro, 2019). This makes the MEP not just executable, but proof-carrying with respect to a fully formalized machine model.

The same drive toward aggressively minimal executable sufficiency appears in Ribbit, but oriented toward compact implementation rather than theorem proving. Ribbit’s R4RS-compliant REPL is a single Linux ELF binary with no external dependencies and a smallest reported size of 6.5 KB when using Prim-no-arity, Optimal (256) encoding, and LZSS compression (O'Leary et al., 2023). Its total size is described by

$$S_{\text{total}} = S_{\text{headers}} + S_{\text{text}} + S_{\text{rodata}} + S_{\text{data}} + S_{\text{bss}}.$$

The compactness comes from a six-instruction Ribbit Virtual Machine, whole-program analysis, feature gating, base-256 RIBN embedding, program-specific optimal encoding, and an x86 assembly host that avoids libc and performs all IO via Linux syscalls (O'Leary et al., 2023). The paper reports the following x86 assembly host footprints for the R4RS REPL: 14 KB baseline, 13 KB with Prim-no-arity, 9.8 KB with Optimal encoding (92), 9.2 KB with Optimal encoding (256), 9.0 KB with Prim-no-arity + Optimal (92), 8.4 KB with Prim-no-arity + Optimal (256), 6.6 KB with Optimal (256) + LZSS, and 6.5 KB with Prim-no-arity + Optimal (256) + LZSS (O'Leary et al., 2023).

The contrast is instructive. In MM0, the MEP is minimal because proof obligations, semantics, and trusted code are minimized. In Ribbit, it is minimal because byte footprint is minimized while preserving a full R4RS REPL. In both cases, however, the artifact is self-contained and executable at the machine level.

6. Traceability, witness execution, and adjacent proof-oriented uses

The contract-traceability paper introduces the adjacent concept of a Minimal Executable Proof, but its treatment clarifies an important boundary for MEPs. The program component is the smallest multi-language set of implementations needed to instantiate contract C01: each program must emit the exact UTF-8 byte sequence Hello, world!\n on stdout, emit zero stderr bytes, and exit with code 0 (Kasselman, 27 May 2026). The proof component links that contract to six implementations in Rust, Go, C, Java, TypeScript, and AWK, a single implementation DAG, a traceability file, a readiness gate, and an evidence matrix, all checked through executable witnesses and structural validators (Kasselman, 27 May 2026).

The artifact’s implementation DAG has nine units, layer counts {0: 8, 1: 1}, entry points U01, U02, U03, U04, U05, U07, U08, U09, leaf nodes U06, U07, U09, and a critical path U05 → U06 with critical-path LOC 138 (Kasselman, 27 May 2026). The runtime witness run_all.sh checks C01 by comparing stdout bytes via cmp, verifying stderr byte count is zero and exit code is 0. On the reported runner, the harness produced 5 PASS outcomes, 1 SKIP for Java because javac/java was not on PATH, and 0 FAIL outcomes; the Go and AWK sidecar witnesses also passed; DAG, traceability, review readiness, contract declaration, and evidence matrix validations all passed; and IJB conformance passed only when invoked with --repo-root (Kasselman, 27 May 2026).

This is not presented as a benchmark, a claim of general semantic equivalence, or a production assurance system (Kasselman, 27 May 2026). The contribution is instead a compact, falsifiable artifact. That distinction matters for encyclopedia treatment of MEPs because it shows how minimal executable artifacts can serve not only as software objects but as evidentiary anchors linking code, contracts, and review procedures.

A plausible implication is that MEP and Minimal Executable Proof sit on a continuum. At one end, the executable is minimized to expose semantic behavior; at the other, the surrounding validation and traceability scaffolding is also made minimal, executable, and falsifiable.

7. Misconceptions, limitations, and research directions

A recurring misconception is that “minimal executable” implies either triviality or universality. The papers support neither claim.

MEPs are often deliberately incomplete. Hornet is not yet feature complete: full script execution integration into block validation, UTXO set evolution, disk storage, and broader peer management remain pending, and some consensus formulas are referenced but not spelled out, including difficulty retarget, precise weight formula, and chainwork increment (Sharp, 19 Sep 2025). The GPU framework notes limitations in environment fidelity, kernels tightly coupled to global state or inter-kernel pipelines, and challenges reproducing representative workloads under the prescribed runtime budget (Chu et al., 15 Dec 2025). MM0’s ISA coverage is partial, ELF is limited to a single PT_LOAD segment with no linking or relocation, and concurrency, signals, and complex OS behavior are out of scope (Carneiro, 2019). Ribbit omits floating-point arithmetic, hygienic macros, multiple values, and some non-essential syntactic forms not required by R4RS (O'Leary et al., 2023). The traceability artifact explicitly disclaims benchmark, scalability, semantic-equivalence, and production-assurance claims (Kasselman, 27 May 2026).

Another misconception is that minimality is synonymous with small file size. That interpretation fits Ribbit directly and appears indirectly in the 2006 arXiv record noting a way to execute a binary file on Windows and ELF-based systems for software installers and other applications not exceeding 64 kilo bytes [0612079]. But in the other works, minimality chiefly concerns semantic surface area, dependency boundaries, specification burden, or validation scope rather than byte count alone.

Several forward directions are explicit in the corpus. Hornet plans DSL-to-C++ backends, differential testing against Hornet Node and Bitcoin Core, and AI-driven adversarial testing at cloud scale (Sharp, 19 Sep 2025). The GPU framework points to richer mocks for allocators and schedulers, automated fidelity tuning, broader pattern libraries, and multi-kernel co-optimization in a composed MEP (Chu et al., 15 Dec 2025). MM0 positions the MEP as a base case for a minimal verifier capable of verifying its own binary (Carneiro, 2019). Ribbit speculates that a complete R7RS REPL could fit in 15–30 KB using the same techniques (O'Leary et al., 2023). The traceability work suggests extension by adding languages, validators, or source profiles while preserving explicit SKIP and FAIL semantics (Kasselman, 27 May 2026).

Taken together, these works support a general characterization: an MEP is a smallest sufficient executable substrate for a specific epistemic task. That task may be specification, optimization, proof, conformance, or traceability. What remains constant is the insistence that the artifact be runnable, bounded in scope, and directly checkable against the property it is meant to preserve.