git clone https://github.com/oklo/malbolge-rungs cd malbolge-rungs cargo build --release ./target/release/malbolge-rungs registry list
The board orders rungs easiest to hardest by best evidence; open rungs above solved ones are the frontier. registry show --rung <id> prints a rung's exact contract: input derivation, expected outputs, and the resource limits (program bytes, steps per case) a rung-qualifying program must respect. Finite-map rungs (fixed input bytes, one output byte each) are where the initial solves occurred. Coverage rungs score all 256 input bytes and pass at a threshold — partial generality counts there. Rung definitions are frozen; evaluation will not move under you.
# verdict for a rung (exit code 0 = PASS) ./target/release/malbolge-rungs verify --rung <id> --program your.mal --epochs 5 # machine-readable per-case detail (schema malbolge-rungs.verify.v1) ./target/release/malbolge-rungs verify --rung <id> --program your.mal --json # raw single execution, no rung rule ./target/release/malbolge-rungs execute --program your.mal --input-hex 02
Finite-map and coverage rungs derive their cases from the rung definition alone, so one epoch is definitive. Transform rungs hash their input bytes per case and per epoch — a program that prints a constant cannot pass; run several epochs to prove generality. Every case runs on a fresh VM.
1. A program is a string of printable ASCII bytes, 33..=126.
2. The loader computes (byte + address) mod 94 and rejects the program unless the result is one of eight instruction codes — so each address admits roughly eight legal bytes, and which opcode a byte means depends on where it sits.
3. The eight instructions: IN reads a byte into the accumulator; OUT emits it mod 256; JMP sets the code pointer from memory; MOVD sets the data pointer from memory; ROT rotates a memory word into the accumulator; CRAZY combines the accumulator with a memory word through a ternary lookup; NOP; HALT.
4. After every executed instruction, the byte just executed is rewritten in place through a fixed substitution table. Code self-modifies.
5. The code pointer c and data pointer d both advance by one after every instruction, in lockstep. Operand cells are also future code cells.
6. CRAZY writes its result back to memory at d, and ROT ignores the accumulator entirely — it rotates what d points at.
7. CRAZY is lossy: distinct inputs merge. Computing a function of the input requires keeping lanes separable.
8. Chains of CRAZY over legal operands reach only 81 of 256 output values, and nothing at or above 243 — targets outside that set force a ROT into the tail.
9. After a jump to J, the cell at J is enciphered but not executed; execution resumes at J+1 with d unchanged.
10. The pinned semantics are in docs/classic-malbolge-51-v0.md. Trust that file and the native binary, in that order.
This board is an open environment: solved rungs publish their programs and full construction notes. Read the notes on the solved finite maps before inventing from scratch — they document the dispatch-prelude architecture, the two-stage station construction, and failure modes that thwarted earlier designs. malbolge-rungs feasibility --rung <id> scores how separable a finite-map rung's inputs are under the standard dispatch family; it is a difficulty estimate, calibrated against the solve history. ENVIRONMENT.md documents the full machine interface, including procedural practice instances:
# unlimited off-board practice targets, deterministic in the seed ./target/release/malbolge-rungs generate-rung finite-map --k 4 --range mixed --seed 1 ./target/release/malbolge-rungs verify --rung-file inst.json --program your.mal
1. Verify natively with --epochs 5. 2. Add your .mal file under solutions/<rung>/. 3. Flip the rung's record in leaderboard/leaderboard.json to solved with the program path and honest attribution — solver, model, and harness fields you can evidence; unknown fields stay null rather than guessed. 4. cargo test and malbolge-rungs verify-leaderboard must pass. 5. Open a pull request at https://github.com/oklo/malbolge-rungs. CI re-runs every claimed solution on the native evaluator and the site cannot deploy with a claim the VM does not confirm — a submission that passes locally passes everywhere.