BRC-173 Introduces Bitcoin BASIC Compiler and Decompiler for Covenant Scripts

Covenant Development Watch / Developer Tools

In Brief

BRC-173 introduces Bitcoin BASIC, a readable BASIC-like language that translates directly to Bitcoin Script, together with a compiler and decompiler for moving between the two representations. The standard is aimed particularly at complex covenant development, where raw stack-based Script can become difficult to review safely. A working browser implementation can compile Bitcoin BASIC, decompile existing locking scripts retrieved from BSV Blockchain, and test whether the resulting representation recompiles to equivalent Script.

News Report

A newly published Bitcoin Request for Comments proposes a higher-level way to both write and inspect Bitcoin Script without introducing a separate virtual machine or execution environment.

BRC-173, “Bitcoin Script to and from Bitcoin BASIC — a compiler and a decompiler,” was published August 28. It defines a BASIC-like language whose constructs correspond directly to existing Bitcoin Script operations, together with rules for translating in both directions.

Bitcoin Script is fundamentally a stack-based language. Its opcodes manipulate values according to their position on a stack rather than through familiar variable names, expressions and structured program blocks.

That is manageable for small locking scripts, but the difficulty rises sharply as covenants become larger and carry mutable state, branching logic or repeated calculations.

BRC-173 approaches that problem by adding a readable source representation while leaving the underlying execution model unchanged.

A developer can write expressions such as assignments, conditionals and verification rules in Bitcoin BASIC, while the compiler converts them into the corresponding Script opcodes. The language also provides fixed-width state declarations and bounded FOR loops, with loops expanded into finite Script at compile time rather than introducing runtime looping that Bitcoin Script does not have.

The proposal deliberately requires the compiler to refuse constructs that cannot be represented faithfully in Script rather than approximating them.

It also performs structural checks that are difficult to manage manually. For example, both branches of a conditional must leave the stack in a compatible shape. If they do not, a conforming compiler must reject the program rather than produce Script whose error may only become apparent later in execution.

The more unusual part of BRC-173 is the reverse direction.

Its decompiler is designed to accept an existing locking script, including a script the user did not create, and render its operations into a more structured Bitcoin BASIC representation.

This is particularly relevant to covenants because once a locking script has been published and funded, the bytes themselves determine what the covenant can do. Reviewing only the original developer’s source code does not independently establish that the deployed script contains the same logic.

BRC-173 therefore treats the deployed Script as the source of truth.

The decompiler operates on the actual parsed script, assigns readable names and expressions where possible, and must report when it can no longer track the stack reliably rather than guessing at the missing structure.

The proposal sits above rather than replacing existing Script representations.

BRC-15 provides Bitcoin Script assembly representation, while BRC-106 standardizes deterministic translation between raw Script and ASM. Those formats preserve the opcode sequence but do not attempt to reconstruct higher-level concepts such as expressions, named state fields or conditional structure.

Bitcoin BASIC adds that higher-level interpretation while retaining a required round-trip property: a program produced by the decompiler must compile back into Script with equivalent behavior.

The reference implementation has already been made available as a browser-based workbench. It can compile Bitcoin BASIC, decompile Script and read a locking script directly from BSV Blockchain without requiring a local installation.

The implementation has also been archived on-chain.

BRC-173 identifies an approximately 200 KB archive containing 15 files and reports that the archive was recovered from its transaction, unpacked and run through its included test suites. The specification reports successful runs of 42/42, 18/18 and 10/10 tests.

The standard also reports round-trip measurements on 15 decompiled programs. All 15 recompiled to semantically equivalent Script, while nine reproduced the original bytes exactly. The six non-byte-identical examples contained loops that had been expanded during compilation and therefore could not be reconstructed as loops by examining only the resulting Script.

Several covenant examples are included in the implementation and testing material, including noughts-and-crosses logic, a Space Invaders-style example and a Rule 110 cellular automaton.

BRC-173 also connects directly with BRC-171, published in the same group, which defines a standard fixed-width layout for mutable state carried inside a covenant’s own locking script. Bitcoin BASIC can use declarations for those fields and generate the corresponding extraction and rebuilding logic automatically.

That relationship also extends to BRC-172, which BSV TIMES covered on August 30. Its self-funding covenant examples use the BRC-171 state model, and the BRC-172 documentation points to the same decompiler as a way to render a deployed covenant containing more than a thousand opcodes into a shorter readable listing.

BRC-173 does not define covenant funding, ownership, authorization or application logic. Its scope is narrower: establish a reproducible translation between readable structured source and the Script that actually executes.

BSV TIMES Read

The important contribution of BRC-173 may be the decompiler as much as the compiler.

A higher-level language can make Bitcoin Script easier to write, but infrastructure becomes more trustworthy when somebody other than the original author can also inspect what was actually deployed.

That distinction becomes increasingly important as covenants grow from short payment conditions into larger pieces of persistent application logic. A few thousand stack operations may be valid and deterministic while still being impractical for a human reviewer to understand directly.

Bitcoin BASIC does not make Script more powerful and does not hide it behind another runtime. Its value is almost the opposite: it attempts to make the underlying Script easier to reason about while preserving a route back to the actual bytes.

If that round trip remains reliable across independently developed implementations, covenant tooling could begin to resemble mature software tooling more generally: developers work with readable source, machines compile it, and reviewers can independently reconstruct and compare what was ultimately deployed.

For public infrastructure, readability is not merely a convenience. When execution rules are permanent once funded, the ability to inspect those rules before relying on them becomes part of the security model.