Disclaimer
This is a continuation of a series of proof of concepts exploring Bitcoin Script as a computational substrate. Parts 1 and 2 are documented here. No “firsts” are being claimed and the idea of “Autoglyphs but on Bitcoin” in Part 3 isn’t interesting in itself. The goal is to put something concrete on the table that sparks conversation about what “onchain” actually means on Bitcoin, and how far the existing script system can be pushed without protocol changes or offchain dependencies.
1. Background
Parts 1 and 2 established that Bitcoin Script can enforce generative art parameter choices at the consensus level. Part 1 encoded a parameter space in a taptree where spending a leaf was the generative act leading to the choice permanently committed onchain. Part 2 added arithmetic validation of witness-supplied values and a collector signature gate, preventing frontrunning. Both parts produced visual outputs via a shared JavaScript renderer, with Ordinals handling the inscription architecture that connected the chain activity to the display layer.
The limitation both parts share is that Ordinals is load-bearing. The parent-child inscription relationship and the recursion infrastructure are required for the pieces to resolve. The artwork exists on Bitcoin but depends on the Ordinals protocol stack to function as intended.
Part 3 asks what happens when you remove that dependency.
2. The Idea
The closest reference point for what Part 3 is trying to do is Autoglyphs on Ethereum (Bitglyphs and hashrunner’s work also come to mind). The Autoglyphs contract enforces a set of rules and produces data and the visual output is what happens when you render that data in a monospace font. The artwork lies in the contract itself, with the visuals being a convention for representing onchain data. Anyone can independently reproduce the output by reading the contract and applying the same interpretation.
Part 3 does the same thing on Bitcoin. A set of 13 puzzle instances are deployed as P2TR outputs on mainnet with each output spendable by anyone who finds a valid witness satisfying a constraint system defined entirely in Bitcoin Script. A confirmed spend is the artifact that permanently records the witness values in the transaction for the onchain data. Interpreting those values as an 8x8 ASCII grid is a published convention, not something the chain enforces. The chain enforces the rules but what the data looks like is up to whoever reads it.
The key difference from Autoglyphs is that the output is not deterministic from the rules alone. There is no single correct answer per puzzle and the valid solution space is large, the artist having no knowledge of what any specific solution will look like. The ASCII output of a confirmed solve is emergent and represents whatever satisfies the constraints.
3. How It Works
Each puzzle instance is a Bitcoin transaction output locked by a tapscript. The script enforces a 2D constraint system over 16 four-byte integers provided in the witness. Those 16 integers, read in order, represent an 8x8 character grid where each integer encodes 4 ASCII characters with two integers per row over eight rows total.
The constraints are:
- Every integer must fall within a per-puzzle committed range
- Adjacent integers in the 4x4 arrangement of chunks must be within a tolerance T of each other
- Integers that share a grid row must be within T/2 of each other, a tighter constraint that produces horizontal coherence
This is 48 constraints enforced by opcodes available on mainnet today. The constraint structure is a discrete harmonic condition where each value is bounded by its neighbors, producing local smoothness in valid solutions without fixing specific values.
One limitation is that script cannot enforce that every byte of a witness integer falls in printable ASCII range. That would require string manipulation opcodes not available in current Script. The ASCII interpretation is applied to whatever values satisfy the arithmetic constraints. Most bytes in valid solutions will be printable given the min/max ranges committed in each puzzle, but this is a consequence of the ranges chosen, not a consensus guarantee.
Each puzzle has distinct parameters (T, min, max) derived from the chronological spend TXID history of Parts 1 and 2. The first 13 TXIDs from Parts 1 and 2, sorted by block height, are the source. This connects Part 3 cryptographically to the prior work with the parameters fully reproducible from chain state.
| Puzzle | T | min (hex) | max (hex) |
|---|---|---|---|
| 0 | 1045 | 0x3201EE8A | 0x52220EAA |
| 1 | 1008 | 0x2C6CE60D | 0x4C8D062D |
| 2 | 658 | 0x2EF65C0B | 0x4F167C2B |
| 3 | 3689 | 0x3B97945C | 0x5BB7B47C |
| 4 | 4946 | 0x2DBF05BF | 0x4DDF25DF |
| 5 | 941 | 0x253F614C | 0x455F816C |
| 6 | 3554 | 0x352D45B0 | 0x554D65D0 |
| 7 | 1053 | 0x2638CBD3 | 0x4658EBF3 |
| 8 | 2074 | 0x3D719FFE | 0x5D91C01E |
| 9 | 4818 | 0x3CB89B28 | 0x5CD8BB48 |
| 10 | 4822 | 0x2CC76586 | 0x4CE785A6 |
| 11 | 749 | 0x35202B8C | 0x55404BAC |
| 12 | 2225 | 0x2FB6BF0F | 0x4FD6DF2F |
4. The Collection
The collection is funded by a single transaction sending 10,000 sats to each of the 13 puzzle addresses. All 13 are distinct P2TR outputs. The NUMS internal key is used for all instances, making key-path spending provably impossible. Only a valid script-path spend satisfying all 48 constraints can unlock any output.
The first confirmed solve is puzzle 0, spent at block 941900. Puzzle 0 was frontrun in the mempool but the proof is valid, meaning the system worked as designed. This is consistent with the permissionless architecture as the constraint system and puzzle addresses are public, and anyone who finds a valid witness can spend. The solve is valid regardless of who broadcast it.
An Ordinals display layer exists for confirmed solves. A shared renderer inscription fetches the spend transaction via the Ordinals recursive endpoint and renders the ASCII grid. Per-piece inscriptions embed the spend TXID and load the renderer. The display layer is a convenience but the confirmed transaction is the complete artifact whether or not any Ordinals infrastructure exists.
| Asset | ID / TXID | Block |
|---|---|---|
| Funding TX | 5a6750eec756454da070ac0569d8ab01858031ece95f8f5b324bd75bc10af1a5 | 941897 |
| Puzzle 0 spend | 779e41b099e43051c33f60bf518a6ca1a22d7b271df8f5fca6f0171dd7b2d785 | 941900 |
| Parent inscription | 64ad7eb9260e3286b053d4c4f49db774114ca6320c4f4d0d9f3735f4049203fci0 | 941907 |
| Renderer inscription | 8d4fe192c4851367801db793e49b1eb004bd1942ac20a069645f742b361f5a0bi0 | 941909 |
| Piece 0 inscription | f845aafb8aababc9514d4219c1331563017c4810da4589b3e02f1b7b928a1fd6i0 | 941911 |
The funding TXID and puzzle addresses in the table above are the complete starting point for anyone who wants to engage with this independently. From the funding TXID you can locate all 13 puzzle outputs onchain. From each puzzle address you can decode the tapscript and read the constraint parameters directly. From any confirmed spend TXID you can extract the witness values, verify all 48 constraints yourself, and reconstruct the ASCII grid without trusting anyone or anything outside the chain.
This is trustless minting on Bitcoin L1 in a sense, meaning a confirmed spend is the mint event. Anyone who constructs a valid witness and gets it confirmed has minted a piece by satisfying a constraint system enforced by Bitcoin consensus. The Ordinals inscription that follows is a display layer, not the mint. This inverts the standard Ordinals model where the inscription is the mint and the artist controls issuance.
5. Solving a Puzzle
Participation does not require writing a solver from scratch or having deep Bitcoin development experience. At the simplest level, anyone can look up the funding transaction, find the 13 puzzle outputs, and watch the collection’s solve state evolve over time directly onchain.
One step further, anyone can take a confirmed spend transaction, pull the witness values, and render the ASCII grid themselves using the convention described in section 3, no tools beyond a transaction explorer and basic arithmetic.
For those who want to go further and attempt a solve, the constraint system is fully described here and the puzzle parameters are readable from the tapscripts on chain. The barrier to entry scales with how deep you want to go.
A valid witness is a set of 16 four-byte little-endian integers satisfying all 48 constraints for a given puzzle. The solution space is large and finding a valid witness is a search problem, not a cryptographic one. A constrained random walk can work by generating a candidate set of 16 integers in the valid range, checking all 48 constraints, and repeating until they all pass. Tighter puzzles (lower T) take longer.
Once you have a valid witness, you (or AI) can construct a standard P2TR script-path spend transaction. The witness stack is the 16 integers, followed by the tapscript, followed by the 33-byte control block. Broadcast it directly to the network.
Note: your transaction will be visible in the mempool before it confirms. An automated actor monitoring the mempool may copy your witness and broadcast a competing transaction with a higher fee, getting confirmed first. If this happens, your witness is still valid and your work is still verifiable. The replaced transaction remains visible in mempool history. Send me your original transaction TXID and/or raw hex and I can verify your witness from that record and inscribe the piece to your address. You found the solution, the bot just paid the miner fee.
6. The Progression
Part 1 uses script-path-encodes-choice where the chain records a navigation, and Part 2 uses witness-encodes-choice where the chain enforces and records a validated computation. Part 3 uses script-as-constraint-system where the chain confirms proofs. Each part makes a more aggressive claim about what Bitcoin is doing. Part 3 makes the most aggressive claim available on mainnet today: the chain is sufficient enough for Bitcoin Script to be a constraint system and confirmed transactions are proofs within it.
The outputs do not exist until they are minted. The content is not stored anywhere before the solve and it comes into existence at the moment a valid witness is confirmed, determined entirely by whoever found it and what they found. With this, there is no artist predetermination or offchain dependency in the minting event.
This is what the smart contract art community has been doing on EVM chains for years; trustless minting, onchain generation, runtime outputs determined by the chain itself, but realized on Bitcoin using only the primitives that have existed in Script since Taproot. The computation happens at the protocol level and the output is whatever the protocol confirms.
The caveat is that Bitcoin Script is not the EVM. The constraint system here is simpler than what a Solidity contract can express, and the visual surface reflects that. The outputs are austere but the claim being made, that a Bitcoin transaction can be a generative mint event with no artist in the loop, is the same claim.
Where this goes depends partly on what Bitcoin gets. OP_CAT, if activated, would close the gap significantly. Per-byte ASCII range enforcement and hash-based proof-of-work on the witness data becomes possible. The constraint system could be made arbitrarily richer and a version of this project built on OP_CAT would be able to make stronger claims about what the chain enforces, not just what it permits. The outputs described in this document as a social convention would become consensus-guaranteed properties.
Short of new opcodes, the directions that remain open today are multi-transaction constraint systems where each spend in a chain of transactions contributes one parameter and the full output is only deterministic once the chain is complete, multi-party schemes where distinct keys must cooperate to produce a valid witness, and richer arithmetic constraint systems that push further into the space of what addition, subtraction, and comparison can express across many witness values simultaneously. None of these require protocol changes, they just require more careful script design.