We are currently working on new rules for what content should and shouldn't be allowed on this website, and are looking for feedback! See Esolang:2026 topicality proposal to view and give feedback on the current draft.
Nonce
| Paradigm(s) | imperative |
|---|---|
| Designed by | User:AndrewBayly |
| Appeared in | 2026 |
| Type system | untyped |
| Memory system | cell-based, tape-based |
| Dimensions | one-dimensional |
| Computational class | Turing complete |
| Reference implementation | JavaScript (browser-based) |
| Influenced by | Brainfuck, Trapdoor |
| File extension(s) | .nonce (unofficial convention; not specified by the language) |
Nonce is an esoteric programming language created by User:AndrewBayly in 2026, in which a program's validity — not merely its meaning — is gated by a proof-of-work condition. A Nonce program is an ordinary Brainfuck program that has been extended with a suffix chosen so that the SHA-256 hash of the entire source file begins with a run of zero bits. Finding such a suffix is computationally expensive; confirming that one has been found is a single hash computation. Nonce belongs to a family of languages built around this kind of write/verify asymmetry, replacing an earlier language in that family, Trapdoor, with a scheme that needs no secret held by the designer.
Source format
A Nonce source file consists of exactly three parts, concatenated with no additional structure:
<brainfuck program>< ><nonce>
- BF program – valid Brainfuck source using only the eight standard commands (
> < + - . , [ ]). No whitespace or other characters are permitted within this part. - Space – a single ASCII space (
0x20), acting as the delimiter between the program and the nonce. - Nonce – a string of one or more ASCII
0and1characters, chosen by the programmer.
For example:
+[.+] 1100010110011110
Validity condition
Let k be the difficulty parameter fixed by the language (see Demo mode below). A Nonce source file is valid if and only if the SHA-256 hash of the entire file, taken as raw ASCII text with no other encoding, begins with k zero bits. In the reference specification, k = 32, so a valid file's hash begins with four 0x00 bytes.
Validity is a property of the file, not of the program's runtime behavior: an invalid file is rejected outright by a conforming interpreter and is never executed, regardless of what its Brainfuck portion would otherwise do.
Interpreter pipeline
A conforming Nonce interpreter processes a source file as follows:
- Split the source on the first space character. Everything before it is the candidate BF program; everything after it is the candidate nonce.
- Compute the SHA-256 hash of the entire, unsplit file.
- Count the file's leading zero bits. If fewer than k are present, reject the file; execution does not proceed.
- Otherwise, execute the BF program under normal Brainfuck semantics.
Because step 2 hashes the file as a whole, the split in step 1 exists only to separate program from nonce for the reader/programmer; the interpreter does not need to have performed the split before hashing.
Execution model
Once a file passes the validity check, its BF portion runs as ordinary Brainfuck: a linear tape of cells, a data pointer, and the eight standard commands. As with classical Brainfuck, the language leaves cell width and tape length unspecified. Reference implementations commonly use 8-bit cells that wrap on overflow/underflow (so 255 + 1 = 0 and 0 - 1 = 255) and a tape whose pointer wraps at both ends rather than erroring – both are implementation choices rather than requirements of the Nonce specification itself, inherited directly from common Brainfuck practice.
Nonce-finder tool
Because a programmer cannot generally choose a nonce by inspection, writing a Nonce program in practice means running a separate nonce-finder: a short, unremarkable program that repeatedly appends a candidate bit-string to the BF source, hashes the result, and checks the leading-zero-bit count. Pseudocode:
program := "<the BF source>"
loop:
nonce := next candidate bit-string
file := program + " " + nonce
hash := SHA256(file)
if leading_zero_bits(hash) >= k:
output file
stop
The tool itself is trivial to implement; essentially all of the work is in the loop's expected iteration count, not its logic. This is the intended asymmetry: the designer of a Nonce program does no more implementation work than the runner of one – both need only a standard SHA-256 routine – but the writer must additionally spend a large, difficulty-controlled amount of computation before a valid file exists at all.
Existence of a valid nonce
Nonce places no upper bound on nonce length, which matters for whether a valid nonce is even guaranteed to exist for a given BF prefix. Modeling SHA-256 as a random oracle, each distinct candidate nonce succeeds independently with probability 2−k. Since the search space of candidate nonces is unbounded, the probability of failure after m independent attempts is (1 − 2−k)m, which tends to 0 as m → ∞. A valid nonce therefore exists for any BF prefix with probability 1 in the limit, and in practice the search terminates quickly relative to that limit: at m = 5·2k attempts, the chance of still not having found one is under 1%.
This is a heuristic argument, not a proof: it rests on the assumption that SHA-256 has no exploitable structure correlating a given prefix with its hash outputs under space-padding, which is unproven but has survived over a decade of public cryptanalysis, including in exactly this kind of leading-zero-bit search (see Bitcoin mining, which performs the same search at global scale continuously). Fixing the nonce to a specific length instead of leaving it open would remove this guarantee: a fixed pool of 2k candidates has a substantial chance (roughly 1/e, by a Poisson approximation) of containing no valid nonce at all, leaving the programmer with no legal file to write. The open-ended nonce length is therefore load-bearing for the language's usability, not a cosmetic choice.
Demo mode
At the specification's difficulty of k = 32, finding a nonce takes on the order of 232 ≈ 4.3 billion hash attempts on average – hours to days on ordinary hardware, though dramatically less on parallel or specialized hardware of the kind used for Bitcoin mining. For demonstration purposes, implementations may offer a reduced difficulty (commonly k = 8, where roughly 1 in 256 candidates succeed) that exercises the full pipeline – construction, search, hashing, validation, execution – in well under a second. Demo mode does not change the language; it only lowers k for illustrative runs, and a file valid under a lower k is not a valid Nonce program under the k = 32 specification.
Example
The program +[.+] starts at cell value 0, increments to 1, then loops – printing and incrementing – until the (8-bit, wrapping) cell overflows back to 0, at which point the loop exits. It therefore prints byte values 1 through 255 in order and halts, rather than running forever.
Searching at k = 8 with this program as the prefix finds, for instance:
+[.+] 1100010110011110
whose SHA-256 hash is 006f0eebc3e5b01d1933abdf040f174afdf280fe4e8c189de14ec9155a48ac2f – 9 leading zero bits, meeting the k = 8 target. This can be checked independently with any SHA-256 tool, e.g. on a Unix-like system:
printf '%s' '+[.+] 1100010110011110' | sha256sum
Relationship to other languages
Nonce is a member of an asymmetry family of languages sharing the property that writing a valid program is hard while running one is easy, alongside languages such as Trapdoor, PrimeScript, Square, Hard, and PrimeIndex. It shares its host language with Normal, another member of the family built on Brainfuck.
Nonce was designed as a successor to Trapdoor, which achieves the same write/run asymmetry differently: the language designer publishes a semiprime N = p × q while keeping q secret, and a program is valid if its source, read as an integer, is divisible by q. Trapdoor's hardness for outsiders rests on the difficulty of factoring N; Nonce's hardness rests on the preimage resistance of SHA-256. The two designs trade off differently:
| Trapdoor | Nonce | |
|---|---|---|
| Secret required | Yes (the factor q, held by the designer) | None |
| Existence of a solution | Provable for the designer, contingent on the host language's padding freedom for outsiders | Heuristic, converging to certainty as search length is unbounded |
| Cost for the secret-holder | Effectively free (direct construction) | Same as for anyone else |
| Cost for everyone else | Search space of size q, typically vastly larger than any practical proof-of-work target | Search space of size 2k, tunable and identical for all parties |
Because nobody – including whoever wrote the language specification – holds a shortcut in Nonce, its difficulty parameter k functions as a single public dial with the same meaning for every programmer, which is not achievable in Trapdoor's design.
Computational class
The BF portion of a Nonce program runs under standard Brainfuck semantics and is Turing complete under the usual idealization of an unbounded tape. The proof-of-work admission check does not add computational power to programs that pass it; it only restricts which Brainfuck programs are legal Nonce source, so Nonce is Turing complete in the same sense, and by the same argument, as Brainfuck itself.