What Siggi Built
A compiler, a virtual machine, and a quiet rewrite of what Bitcoin Script can do
Most technical people in crypto, if you asked them, would tell you that Bitcoin Script cannot do very much. It is a stack-based language without loops, without recursion, without the ability to do arbitrary computation. It exists to authorise spends. That is its job.
Most technical people in crypto, if you asked them, would also tell you that Ethereum is where smart contracts happen. The EVM is where the value-locked lives. Layer 2 rollups — Arbitrum, Optimism, zkSync, Scroll, Linea — sit on top of Ethereum because Ethereum is where the liquidity is and because Ethereum provides the data availability and the settlement layer that rollups depend on.
If those two statements were both true and permanent, then what Siggi Óskarsson has built over the last year would be impossible. It is not. He has built it, it runs, and it changes the analysis.
This post walks through the two pieces. First, Rúnar — a compiler that takes smart contracts written in any of five high-level languages (TypeScript, Solidity-style, Move-style, Go, Rust) and produces Bitcoin Script, with formal guarantees about correctness. Second, BSVM — a fully EVM-compatible Layer 2 execution environment that runs on Bitcoin SV, where every single state transition is authorised by a STARK validity proof verified on-chain inside a Bitcoin Script covenant that the Rúnar compiler produced.
Each piece is interesting on its own. Together they rearrange the landscape.
Part 1: Rúnar — a real compiler for Bitcoin Script
The problem Rúnar solves
Bitcoin Script, in its post-Genesis form on BSV, is a genuinely capable language. The original Satoshi opcodes are restored. There is no artificial cap on stack item size. There is no artificial cap on transaction size or block size. Arithmetic is arbitrary-precision. Hashing is native. The introspection opcode OP_PUSH_TX lets a script read the transaction that is trying to spend it, which turns out to be the key primitive for stateful contracts.
But writing raw Script is painful. The language is stack-based, which means programmers have to mentally track what sits on the stack at every step, ordering OP_DUP, OP_SWAP, OP_ROLL, OP_PICK to bring values to where they need to be. There are no named variables. There is no if (x > 0) { ... } syntax the way there is in a high-level language — well, there is OP_IF ... OP_ENDIF, but the branches have to balance the stack, and if you get it wrong the transaction silently becomes unspendable. People write Bitcoin Script by hand the way people wrote 6502 assembly in 1980, which is to say: a small number of specialists do it well, and everyone else gets bugs.
What Siggi built, and published in a BSV Association technical report in March 2026, is Rúnar: a compiler that lets programmers write smart contracts in the language of their choice and emits Bitcoin Script bytecode that is correct by construction. The source code is open, hosted at github.com/icellan/runar.
What “multi-frontend” means in practice
Figure 1 shows the architecture. Five source languages — TypeScript, Solidity-style, Move-style, Go, Rust — all parse into a single shared abstract syntax tree (AST). After that, the pipeline is language-agnostic: validation, type checking, lowering to A-Normal Form (ANF), stack lowering, and opcode emission.
Figure 1. Rúnar’s five frontends converge onto a shared Contract AST. After that point the compilation pipeline is syntax-agnostic.
This is an architectural choice that matters for adoption. A Solidity developer can write a BSV contract in Solidity-style syntax and get Bitcoin Script out. A Move developer can write in Move-style syntax and get the same Bitcoin Script out, because the AST is the same after parsing. A Rust developer can use Rust attribute macros on standard Rust structs and get the same Bitcoin Script out. You are not forced to learn a new language to write contracts for BSV. You use whichever language you already know.
But the more interesting architectural decision sits one layer deeper.
The ANF conformance boundary
After the AST is built and type-checked, Rúnar lowers it to an intermediate representation called A-Normal Form, or ANF. ANF is a classical compiler IR in which every sub-expression is bound to a named temporary. So instead of
assert(hash160(pubKey) === this.pubKeyHash)
you get
let t0 = load_param(pubKey)
let t1 = call(hash160, [t0])
let t2 = load_prop(pubKeyHash)
let t3 = bin_op(===, t1, t2)
let t4 = assert(t3)
Why does this matter? Because ANF is simple enough to be canonically serialisable. Two compiler implementations can independently agree on what the ANF for a given source program should be, byte for byte. And Siggi has built three independent compiler implementations — one in TypeScript, one in Go, one in Rust. All three produce byte-identical Bitcoin Script for the same source input.
This is not the same as having one compiler that works. This is a very specific claim about correctness. If there is a bug in the Go compiler that makes it emit semantically wrong Script, the conformance test suite will catch it, because the TypeScript and Rust compilers will disagree. If there is a bug that affects all three — a specification-level bug in how ANF is supposed to lower — it would have to be a bug that three teams working in three different languages, using three different parser toolchains, with three different sets of runtime semantics, all implemented the same way. This is the kind of defence-in-depth that safety-critical software uses. It does not eliminate shared-specification risk, but it cuts most of the error modes that a single-compiler project would be exposed to.
The four things Rúnar proves
The March 2026 technical report states four correctness properties as theorems. Each comes with a proof sketch. They are:-
Type safety. Any program accepted by the type checker cannot encounter a runtime type mismatch in Bitcoin Script. The stack lowerer tracks types through every opcode.
-
Termination. Any program accepted by the validator terminates. The validator rejects unbounded loops and all recursion, which means every program is a finite composition of bounded steps.
-
Determinism. The compiler is a pure function of its input. The same source always produces the same bytecode, regardless of machine, operating system, or time of day.
-
Cross-compiler conformance. All three independent compiler implementations produce byte-identical Bitcoin Script for any valid source program.
These are not marketing claims. Each is backed by the testing infrastructure Rúnar ships with. The cross-compiler conformance is verified by a suite of nine golden-file tests, plus dynamic discovery across the full example-contract corpus. Every contract in the corpus is compiled by all three compilers, and the resulting hex bytes are compared byte by byte. If any single byte differs, the test fails and the commit is rejected.
The post-quantum proof of concept
Here is the claim that most people will find hardest to believe, so let me state it carefully. Bitcoin Script can verify post-quantum signatures. Rúnar compiles them.
Two schemes are implemented. The first is WOTS+, Winternitz one-time signatures, which uses nothing more than hash-chain traversal. The Rúnar WOTS+ verifier compiles to approximately 10.5 KB of Bitcoin Script. The second is SLH-DSA (FIPS 205, the NIST-standardised version of SPHINCS+), which is stateless, hash-based, and quantum-resistant. The SLH-DSA SHA2-128s verifier compiles to approximately 203 KB of Bitcoin Script.
203 KB is a lot for a locking script. It is very much not a lot compared to the 10 MB per-script ceiling on BSV. And the script verifies. The output of the Go compiler, the Rust compiler, and the TypeScript compiler is byte-identical for the same SLH-DSA verifier source, with the identical bytes checked in as a golden file. Anyone who wants to prepare a BSV UTXO that can only be spent under a post-quantum signature can do it today.
This is the kind of thing that people gesture at in forward-looking posts about “quantum-resistant blockchains” and never actually implement. Rúnar implements it. You can download the source and compile it yourself.
What Rúnar does not do
Siggi is careful about the limits. The four correctness theorems are stated as theorems with proof sketches, not as machine-checked proofs in Coq or Lean. The cross-compiler conformance is validated empirically across 50 contracts in the corpus — no discrepancies, but the corpus is not exhaustive. The Go and Rust frontends are single-compiler (you write .runar.go in the Go source form, and only the Go compiler parses it; same for Rust). These are real scope limits, and the paper states them.
What Rúnar does is it makes Bitcoin Script a first-class compilation target for high-level languages, with the correctness discipline that any serious programming-language infrastructure requires. The next piece — BSVM — is what you can build on top of that when you have it.
Part 2: BSVM — an EVM on Bitcoin SV
The idea in one sentence
BSVM is an Ethereum Virtual Machine Layer 2 that runs on Bitcoin SV, where every state transition is authorised by a STARK validity proof verified on-chain in a Rúnar-compiled Bitcoin Script covenant.
That sentence contains four technical claims, so let me unpack them.
“An Ethereum Virtual Machine” means exactly what it sounds like. BSVM runs unmodified EVM bytecode. If you have a Solidity contract, it runs on BSVM. If you have a MetaMask wallet, it connects to BSVM. If you have ethers.js or Hardhat or Foundry, it works against BSVM. There is no BSV-specific contract language you have to learn. From the application developer’s point of view, BSVM looks and behaves like Ethereum.
“Layer 2” means transactions execute off the L1 chain and only the proof of execution is posted to L1. This is how Arbitrum, Optimism, zkSync, and every other rollup you have heard of works. L2s exist because L1 execution is expensive and rollups let you amortise that cost across many transactions per L1 posting.
“Runs on Bitcoin SV” means the L1 is BSV, not Ethereum. This is the unusual part. Every other EVM rollup in production today — zkSync, Scroll, Polygon zkEVM, Linea, Optimism, Arbitrum — uses Ethereum as its L1. BSVM uses BSV. Why BSV? Three reasons: unlimited block size, stable fees, and the OP_PUSH_TX introspection opcode that makes covenants possible. I will come back to each.
“Every state transition is authorised by a STARK validity proof verified on-chain” means that there is no “sequencer” that posts state roots which are taken on faith and challenged only if someone notices. Every state transition carries a cryptographic proof, and that proof is checked by BSV Script at the moment the transition is recorded. If the proof does not verify, BSV’s own script engine rejects the transaction, and no state transition happens. This is validity-proven architecture, the same category as zkSync, not the optimistic architecture of Arbitrum and Optimism that relies on fraud-proof windows.
The core data structure: the covenant UTXO chain
Figure 2 shows the architecture.
Figure 2. The BSVM covenant UTXO chain. Each state advance is a BSV transaction that spends the previous covenant output and creates a new one. The locking script of each covenant output contains the shard’s state root and block number. The unlocking script of each spending transaction contains the STARK proof authorising the transition. Batch data for the transition is published in an OP_RETURN output (or alternative path — see Appendix 2 of the paper).
A BSVM shard has its state committed to a chain of BSV transactions, each spending the previous one. UTXO number zero carries the initial state. UTXO number one is created when somebody spends UTXO zero, and it carries the new state after one batch of EVM transactions. UTXO number two is created by spending UTXO number one, and it carries the state after the next batch. And so on.
The locking script on each UTXO is a Rúnar-compiled covenant. To spend a covenant UTXO you have to provide, in the unlocking script, a STARK validity proof. The covenant runs the Rúnar-compiled FRI verifier on that proof inside Bitcoin Script. If the verifier accepts, the spend is authorised. If the verifier rejects, BSV’s own script engine rejects the transaction, and the covenant UTXO remains unspent.
This is important enough to say twice. The STARK verification happens on the BSV chain, in Bitcoin Script, as a consensus check on every node. It is not something a node operator does optimistically. It is not something that gets challenged later. It is part of the definition of whether the transaction is valid, the same way OP_CHECKSIG is.
Why BSV specifically
Three properties of BSV make the architecture work.
Unlimited block size. BSVM posts batch data to BSV. A 128-transaction batch carries about 20 KB of raw transaction data plus a STARK proof of about 165 KB, for a total transaction size of around 216 KB. On Ethereum, posting 216 KB is expensive because Ethereum blocks have gas limits that implicitly cap data. On BSV there is no such cap. Miners set their own policy limits, and the de facto limits are in the hundreds of megabytes to gigabytes. A BSVM covenant advance is a small transaction by BSV standards.
Stable fees. BSV’s fee rate is about 100 satoshis per kilobyte and has been stable for years. It is not driven by a blockspace auction that spikes during market events the way Ethereum gas prices do. This matters for an L2 because the L2’s operational cost is predictable. A 128-transaction batch costs about 21,600 satoshis, or about $0.0065 at $30/BSV. Divide across 128 transactions and you get about 169 satoshis per transaction, or about $0.00005. This is one and a half orders of magnitude cheaper than any Ethereum-based L2, and the margin does not shrink when someone launches a popular memecoin.
The OP_PUSH_TX introspection opcode. This is the key primitive that makes covenants work on BSV. It lets a script inspect the transaction that is trying to spend it — the outputs, the output values, the script codes. With OP_PUSH_TX, a locking script can enforce that the spending transaction produces a specific next-state output with a specific next-state covenant script. That is the mechanical basis for “the covenant UTXO chain maintains state”. Without introspection, you cannot do stateful contracts on a UTXO blockchain.
Ethereum does not have any of these three properties. Ethereum blocks are gas-capped, Ethereum fees are volatile by design, and Ethereum does not have UTXO covenants (it does not have UTXOs — it is an account model). This is why BSVM is not built on Ethereum. The three L1 properties that BSVM depends on all exist on BSV and none of them exist on Ethereum.
The validity proof pipeline
Figure 3 shows how a user transaction becomes an on-chain state commitment.
Figure 3. Transaction flow in BSVM. The fast path (top) returns a receipt to the user in sub-millisecond time via the Go EVM. The slow path (bottom) runs the same batch through revm inside SP1, produces a STARK proof, and posts a covenant-advance transaction to BSV. The user experience is decoupled from L1 finality.
A user signs a standard EVM transaction in MetaMask and broadcasts it to a BSVM overlay node. The overlay node runs two EVMs. One is the Go EVM — the reference Ethereum implementation, extracted from geth — which executes the transaction in about a millisecond and returns a receipt. From the user’s perspective, the transaction has happened: the wallet shows the new balance, the swap is done, the NFT is minted. This is the “preconfirmed” tier.
Behind the scenes, the overlay node batches up to 128 transactions and hands the batch to the second EVM, which is revm, a Rust EVM, running inside SP1, a zero-knowledge virtual machine. SP1 executes revm in simulated RISC-V and produces a STARK proof that proves the execution was correct. The proof covers every opcode, every gas deduction, every storage write, every balance change. If a malicious overlay node had tampered with the execution, the proof would not verify.
The overlay node takes the proof, packages it into a BSV transaction whose unlocking script contains the proof, and whose outputs are (i) the new covenant UTXO with the updated state root and (ii) an OP_RETURN carrying the batch data. This transaction is broadcast to the BSV network. BSV miners verify the covenant script — which includes running the FRI verifier on the proof — and, if valid, include the transaction in the next block.
At this point the state transition is committed: it is on the BSV chain. After a few more BSV blocks confirm on top, it is finalised: reorganising it would require reorganising the BSV chain itself, which under honest-majority mining is exponentially improbable.
Notice what this buys. The user gets a receipt in milliseconds. The proof follows in seconds. The on-chain finality follows in minutes. The three tiers are decoupled, and the application developer chooses which tier a given action depends on. A DeFi swap can depend on the preconfirmed tier because the preconfirmation is backed by the overlay node’s economic stake (if the proof later fails, the overlay node is slashed). A large bridge withdrawal can depend on the finalised tier because deep reorgs become the threat model.
No sequencer
Here is where BSVM departs sharply from existing rollup designs.
Every production L2 today has a sequencer. The sequencer is a privileged party — usually run by the rollup operator — that orders transactions, submits batches, and posts state roots to L1. If the sequencer misbehaves, users can eventually recover via “escape hatches” that take days. If the sequencer goes offline, the rollup stops working until it comes back. The sequencer is a single point of failure and a single point of trust.
BSVM has no sequencer. The covenant UTXO does not require any particular party’s signature to advance. It requires a valid STARK proof. Anyone in the world who has computed a valid STARK proof over a batch of pending transactions can spend the covenant UTXO and advance the state.
In practice, multiple overlay nodes compete to advance the state. They all execute the same pending transactions deterministically (because the EVM is deterministic), so they all produce the same state root. They race to produce a STARK proof and broadcast the covenant-advance transaction. The first one to get their transaction mined wins. The losers drop their proofs, read the winner’s batch data from the OP_RETURN, replay the batch to confirm the state root, and continue from the new tip.
Figure 4 shows the race.
Figure 4. Three overlay nodes each generate a STARK proof attempting to spend the current covenant UTXO. BSV miners accept only the first valid transaction to propagate. The winner’s transaction advances the chain. Losing nodes replay the winner’s batch data and resume from the new tip. No leader election is required — BSV’s existing double-spend resolution handles the race.
This is not Raft or Paxos. There is no leader election. There is no view change. There is no distinguished “honest majority” among overlay nodes. The consensus is provided by BSV itself. Overlay nodes are free to come and go. A shard with one overlay node still works. A shard with a hundred overlay nodes works the same way. Redundancy is operational, not protocol.
The economic model follows the architecture. The prover that wins the race collects the gas fees from the transactions in the batch. The prover’s cost is the BSV mining fee, which at the reference parameters is about 21,600 satoshis per batch. At a 1 gwei gas price on 128 simple transfers, the prover earns about 268,800 satoshis — a 12× margin. At 128 Uniswap-style swaps, which use more gas, the margin is 89×. These are not rates that require subsidy. A prover with an RTX 4090 GPU running off-peak electricity is profitable from day one.
Bridge and governance
The bridge covenant is separate from the state covenant. It holds BSV in locked sub-UTXOs, each capped at 100 BSV to bound the damage of any single bug. Deposits arrive by sending BSV with an OP_RETURN identifying the destination L2 address; after six confirmations, the overlay node credits wBSV on L2. Withdrawals burn wBSV on L2, include the burn in the batch’s withdrawal Merkle root (committed as a STARK public value), and allow any party to present a Merkle proof to the bridge covenant to claim BSV. There is a timelock — six blocks for small amounts, 100 blocks for large ones — to limit the damage from a hypothetical bridge-covenant bug.
Governance is per-shard and chosen at genesis. Three modes are available. none mode has no privileged keys — the STARK proof is the sole authority, and there is no recovery path from a verifier bug. single_key mode has one governance key that can freeze the shard and upgrade the covenant template, but cannot advance state or touch bridge funds. multisig mode is an M-of-N multisig of the same permissions. The trade-off is explicit: more trustlessness for less recoverability. The shard creator picks the point on the trade-off curve.
Part 3: Why this matters
What the architecture proves is possible
Siggi’s two pieces together establish several things that most of the technical commentariat in crypto has denied for years.
First, Bitcoin Script is more powerful than most people think. Not because the opcodes are different — they are the same opcodes that have been in Bitcoin since 2009, with the restrictions Satoshi imposed later and Genesis removed. The constraint was never the language. The constraint was that nobody had built a serious compiler for it. Rúnar is the serious compiler.
Second, full EVM compatibility does not require Ethereum. BSVM runs every Ethereum tool — MetaMask, ethers.js, Hardhat, Foundry — against a UTXO blockchain. The EVM is a specification, not a venue. If you build a faithful execution environment for it and anchor it to a blockchain with data availability and settlement, you have an EVM L2. The blockchain does not have to be Ethereum.
Third, sequencerless rollups are not a theoretical curiosity. BSVM has no sequencer. It works. The STARK proof is the consensus object that determines state, and BSV is the availability and settlement layer. Rollup designs that require a sequencer are making a design choice, not accepting a necessity.
Fourth, STARK verification in Bitcoin Script is feasible. The FRI verifier compiles to approximately 85 KB of Bitcoin Script, uses well under the 100 MB stack memory policy ceiling, and executes in under 150 ms on BSV regtest. This is inside the budget. It has been deployed and it runs.
Fifth, the economic model of validity-proven L2s can be driven by L1 properties, not by subsidy. At 100 satoshis per kilobyte on BSV, a BSVM batch of 128 transactions costs $0.0065 in L1 settlement. The prover’s margin at 1 gwei gas is 12×. This is not a promotional rate. It is what the arithmetic says when the L1 is cheap and the proof is ordinary.
What it does not prove
Siggi is precise about the limits of what he has built, so I will be too.
Validity proofs are as strong as the cryptographic assumptions they rest on. SHA-256 collision resistance, the soundness of the STARK proof system, the correctness of the Rúnar compiler output. Each has been studied extensively, none has been broken, but none can be formally proven correct in an absolute sense.
The covenant’s correctness depends on the FRI verifier source code being right. That source compiles through three independent Rúnar compilers and all three agree on the bytecode, which is strong evidence against compiler bugs, but it does not rule out a specification-level bug in how FRI is supposed to work. Independent audit and machine-checked formalisation are the next layer of defence, and both are pending.
BSV’s throughput scaling numbers — the ones that make the L1-is-not-the-bottleneck argument — come from the Teranode reference implementation paper. Those numbers are measured under crash-fault semantics within a single administrative trust domain, which is the right model for enterprise mining but not the open adversarial Byzantine model. The system works within the scope it is measured in. Claims beyond that scope are projections, and Siggi has been careful to frame them as such.
None of these caveats changes what Siggi has actually built. They just make clear where the rigorous claims stop and the engineering judgement starts.
The broader frame
There is a question worth asking about why this architecture could not have been built in 2018 or 2020. The answer is that three things had to converge.
First, STARK prover software had to reach general-purpose maturity. SP1, released by Succinct Labs, is a STARK-based zkVM that proves RISC-V execution. You compile your application (in this case revm) to RISC-V through the standard LLVM toolchain, hand it to SP1, and get a STARK proof of its execution. This is a general-purpose tool, not a bespoke circuit. Custom zkEVM circuits take multi-year, multi-million-dollar engineering efforts; SP1 lets you skip that and use an existing EVM implementation.
Second, Bitcoin Script had to be restored to its original capability. The Genesis upgrade to BSV in February 2020 restored the original Satoshi opcodes, removed the artificial size caps, and lifted the item-count restrictions. Without Genesis, the FRI verifier would not fit in a BSV locking script, because the pre-Genesis script-size limits were a few kilobytes. With Genesis, 85 KB of verification logic fits comfortably.
Third, someone had to actually write the compiler. Rúnar is the piece of infrastructure that makes the rest possible. Without Rúnar, you cannot compile a FRI verifier into Bitcoin Script, because hand-writing 85 KB of bug-free Script is not a realistic ask of any human. Rúnar takes a high-level specification of the verifier, compiles it through its six-phase pipeline, and emits the bytes. Three times, in three languages, with byte-for-byte agreement.
Take any of these three away and the architecture collapses. What Siggi has done is recognise that all three were in place, identify what they combined to permit, and then put in the engineering effort to execute on it.
What happens next
The system is live. The production covenant uses the real FRI verifier path. The SP1 guest program integrating revm is integrated into the live proving stack. The end-to-end path has been exercised. Independent audit is scheduled. Machine-checked formalisation is identified as follow-on work.
The immediate use cases are the ones any EVM L2 opens: DeFi (swaps, lending, derivatives), stablecoins, NFTs, on-chain games. What is different is the cost curve and the trust model. A DEX on BSVM settles for $0.00005 per trade, which is at least an order of magnitude cheaper than any Ethereum L2, and it does it without a trusted sequencer.
The longer-horizon implications are more interesting. A validity-proven EVM on a UTXO blockchain is a design primitive that other projects can use. Shards are independent — each is its own ecosystem with its own overlay nodes, its own covenant chain, its own governance. If you want to launch a new EVM chain, you do not have to negotiate with a sequencer operator or buy space on an existing rollup. You deploy a covenant, stand up an overlay node, and your chain exists. The cost of launching an EVM chain drops to roughly the cost of deploying a contract.
Whether BSVM becomes the dominant architecture for EVM L2s is a question the market will answer. That question was not on the table a year ago. Siggi put it there.
Appendix: where to go deeper
The primary sources are open.-
Rúnar technical report (BSV Association, March 2026). Source code at github.com/icellan/runar. Covers the grammar, type system, six-phase compilation pipeline, stack-lowering algorithm, correctness theorems, and the full empirical evaluation across all 50 contracts in the test corpus.
-
BSVM whitepaper (BSV Association, April 2026). Covers the covenant UTXO architecture, the SP1 guest program, the proof pipeline, the fee model and prover economics, the bridge design, and the security analysis. The companion academic paper submitted to ACM Transactions on Distributed Ledger Technologies extends this with a formal protocol state machine, a system security theorem, an MEV characterisation, and an alternative data-availability path that uses Bitcoin Script directly instead of OP_RETURN.
The academic paper is aimed at reviewers who want the full formal treatment. The whitepaper is aimed at engineers who want to know how to integrate. Rúnar’s technical report is aimed at compiler people who want to understand the ANF conformance boundary and the stack scheduling algorithm.
Reading order, if you are coming to all of this fresh: the Rúnar report first (it is the enabling infrastructure), the BSVM whitepaper second (it is what you build on top), and the academic paper last if you want the formal security model.
What Siggi has built is not a thought experiment. It runs. You can read the code, fork the repo, compile the contracts, and check the bytes. That is, in the end, what distinguishes serious infrastructure from everything else.