Developer Tools / Network & Protocol

A long-running computation does not necessarily have to fit inside one blockchain transaction.

K17 is an experimental stack-machine design that explores a different approach: preserve the machine’s current state inside a UTXO, execute a limited number of instructions when that output is spent, and place the updated machine state into the next output.

The result is a computation that advances across a sequence of transactions.

The public k17-vm repository describes the project as a proof of concept for a UTXO-chained stack computer on BSV Blockchain, implemented with an sCrypt covenant, an off-chain reference virtual machine and a keeper that constructs the next transaction. The broader K17 design has also been published by Jerry D. Chan through Technical Disclosure Commons.

K17 remains experimental. Its repository contains implementation code and local Script tests, while a separate technical addendum describes a public-testnet rehearsal. The repository’s own deployment script, however, is still documented as unused.

That makes the project interesting less as a finished execution platform than as a concrete exploration of how persistent computation can be divided across successive UTXOs.

A Suspended Process Inside a UTXO

The central idea is that one K17 output represents one suspended machine.

Its locking script contains the program and machine state. When somebody wants to advance the computation, they construct a transaction that spends that UTXO.

The covenant verifies that the next output carries the same program with the machine state advanced by exactly the permitted number of instructions.

If the transaction satisfies those rules, the old state is spent and a new UTXO becomes the next suspended state.

The computation therefore does not run continuously.

It moves in cycles:

current machine state → transaction executes a bounded step → next machine state

The current implementation supports a stack-machine instruction set derived from Philip Koopman’s Canonical Stack Machine, with additional instructions introduced for K17’s own requirements.

The repository currently describes 43 handlers in its fuller configuration, including operations for external inputs, signature verification, payments, member rosters, Merkle proofs and execution-state management.

The Keeper Advances the Machine

K17 separates the program from the party that actually constructs the next transaction.

That party is called a keeper.

The keeper reads the current machine state, runs the corresponding step through the off-chain reference VM, determines what the next state should be and builds the spending transaction.

The blockchain Script then checks that transition.

This means the keeper does not gain permission to arbitrarily rewrite the program’s state. It proposes the next step, but the covenant determines whether the transaction correctly follows the machine’s rules.

K17 also introduces an economic incentive for that work.

Its prototype uses a time-based reward mechanism described as a liveness Dutch auction. A keeper can receive a reward from the machine’s balance for advancing it, with the permitted reward increasing according to elapsed time up to a configured cap.

The intention is to give third parties an economic reason to keep a machine progressing even when they did not create the application themselves.

Programs Can Accept Signed External Inputs

Later versions of K17 extend the model beyond closed computation.

A program can consume data supplied through the transaction’s unlocking information, verify conditions around that data and pay a bounty to the party that advances the machine.

The design also supports signed attestations.

For example, an external sensor or other data source can sign a reading. A third party can relay that signed reading to the machine without becoming the authority that originally vouched for its contents.

The machine verifies the signature against the authorized key before accepting the input.

This separates three roles:

• the party that produces or attests to information;
• the party that relays it to the machine;
• and the covenant that decides whether the resulting state transition is valid.

K17’s later roster designs expand this further by allowing authorized participants to be represented either directly in machine memory or through a sparse Merkle-tree root stored as part of machine state.

The tree-based version is designed for a much larger participant set while keeping only the Merkle root inside the machine state. Individual cycles then carry the proof needed for the particular member involved.

Payment Can Be Part of the Computation

K17 also allows programs to release satoshis as part of successful computation.

The BOUNTY mechanism can reward the spender who supplies information satisfying the program’s checks, while later roster instructions can pay an identified member rather than merely the relayer.

That produces an interesting relationship between computation and payment.

A program can effectively say:

provide data satisfying these conditions, advance the machine correctly, and the transaction itself releases the defined reward.

The execution rule and the payment condition are therefore evaluated together.

This does not turn K17 into a general-purpose production compute market. It does, however, demonstrate how a UTXO-controlled program can couple state transitions with economic incentives for external work.

Freeze Escape Addresses a Liveness Problem

Persistent UTXO computation also creates a practical danger: what happens when a machine reaches a state from which nobody can successfully advance it?

The current K17 design includes a Freeze escape mechanism intended to prevent the machine’s deposit from becoming permanently locked.

One case involves a program requiring a witness or external input that nobody can supply. Another involves execution faults created by the program itself.

K17 v3.1 introduces an optional dead-man interval. If sufficient blockchain time passes without valid progress, a keeper can submit a halting cycle that returns the remaining balance to the designated beneficiary rather than requiring the missing witness.

The same version also changes certain unrecoverable program conditions into faults that halt and refund the machine instead of making every possible next transaction invalid.

There is also a minimum clock-advance rule for cycles that keep the machine alive. This prevents a keeper from repeatedly advancing the machine while artificially holding its internal time in place.

These mechanisms matter because a persistent covenant does not only need rules for successful execution. It also needs a defined way to stop when continued execution becomes impossible.

Execution Comes With Large Transactions

K17’s README publishes measurements that make the implementation cost visible.

A very small configuration executing one instruction per cycle with 21 handlers produces a documented final-cycle transaction of 9,574 bytes.

Four instructions with the same 21-handler configuration produce 16,802 bytes.

A larger configuration executing 40 instructions with 43 handlers and the later compact-record optimization produces a documented final-cycle transaction of 183,626 bytes.

These figures are implementation measurements from the K17 repository. They should not be interpreted as network-throughput benchmarks.

Continuing cycles can be considerably larger because they must also carry the next machine-state output. The README gives examples in the hundreds of kilobytes for some live cycles.

The project therefore makes one of its principal tradeoffs visible: general state-machine behavior can be expressed through chained Script transactions, but the present interpreter can require substantial transaction data.

The README identifies interpreter size as an optimization target.

The Clock Also Limits Throughput

Transaction size is not the only constraint.

K17 v3.1 ties live cycles to nLockTime progression.

The README describes roughly one live cycle per block when the keeper tracks the chain’s median-time-past closely, or potentially more cycles when advancing in minimum 60-second increments. That faster path causes the machine’s internal clock to lag and brings its dead-man condition closer in real time.

The repository therefore explicitly states that the machine’s throughput is bounded by the clock rule as well as by Script size.

This makes K17 different from a conventional virtual machine in which a processor simply executes instructions as quickly as hardware permits.

Its execution schedule is part of the transaction and consensus environment in which the machine lives.

Implemented and Locally Tested

The public repository contains the reference VM, covenant contract, keeper logic, sample programs, attestation code and sparse-Merkle-tree implementation.

It also contains test suites for the VM, the sparse Merkle tree and the K17 machine contract.

According to the README, running npm test builds and compiles the contract and exercises it against a local Bitcoin Script interpreter. No network access or funded keys are required for those tests.

That provides a useful maturity boundary.

K17 is more than a conceptual paper: there is executable reference code and a test suite.

But the repository does not present those tests as published production-network validation, and no GitHub Actions workflow currently provides a public continuous-integration record for the test results described in the README.

Public-Network Evidence Needs a Separate Qualification

The K17 repository also contains a deploy.ts script and retains a NETWORK=testnet configuration inherited from its sCrypt scaffold.

However, the README explicitly says that the deploy script has not been used yet.

Separately, K17 Addendum 1, published by Jerry D. Chan through Technical Disclosure Commons, states that a reference implementation with measurements and a public-testnet rehearsal is described.

Those two statements should not automatically be treated as contradictory.

The rehearsal described in the disclosure could involve a different build, repository state or deployment procedure from the unused deploy.ts script currently present in k17-vm.

Without independently verifying the corresponding rehearsal transactions, BSV TIMES would distinguish the evidence this way:

• Implemented: the public repository contains the virtual machine, covenant, keeper and supporting code.
• Locally tested: the repository documents Script-interpreter tests for the implementation.
• Public-testnet rehearsal: described in the technical disclosure, but not independently established here from specific transaction references.

That distinction keeps the project from being described as more operationally mature than the available evidence supports.

More Than a Claim About Turing Completeness

K17 could easily be summarized as an attempt to demonstrate complex or effectively unbounded computation on Bitcoin Script.

That description misses the more interesting systems questions.

The project explores how an application can preserve an execution state across transactions, allow unrelated third parties to advance it, pay those parties for useful work, accept signed information from external actors, maintain participant rosters and recover funds when execution becomes stuck.

Those are questions about persistent state, liveness, incentives and coordination, not merely about how many instructions Script can express.

The UTXO is functioning as a suspended computational object.

Each valid spend becomes the next step in its history.

The keeper provides the work needed to advance it, while miners evaluate the transaction according to the locking rules.

And if the machine can no longer make useful progress, the freeze-escape mechanism provides a path toward termination rather than indefinite lock-up.

K17 remains a proof of concept, and its present transaction sizes and timing rules place meaningful constraints on what the architecture can practically do.

But it provides a concrete implementation of an unusual idea: a program whose persistent execution state is carried from one UTXO to the next, with computation proceeding through a chain of independently submitted transactions.

Developer Context

The K17 defensive publication is authored by Jerry D. Chan and was published through Technical Disclosure Commons.

Its first addendum extends the original design with signed-attestation rosters, sparse-Merkle-tree participant rosters and the Freeze escape mechanism. A second addendum concerning escrow top-ups and third-party funding is referenced by the current repository as submitted for publication.

The public reference implementation is hosted in the Bittoku/k17-vm GitHub repository. Because the public materials reviewed here do not establish whether the GitHub account and publication author should be treated as the same identity, BSV TIMES keeps those attributions separate.

Source Links

K17 VM — Public GitHub Repository

K17 — Technical Disclosure Commons

K17 Addendum 1 — Signed-Attestation Rosters, Merkle Rosters and Freeze Escape

BSV TIMES – Under the Surface

Under the Surface looks at projects, standards, experiments, and community activity that may not rise to the level of a headline but are still worth noticing. Some are new, some are continuing work, and some are quieter developments that help show what is taking shape across the BSV community.

Update — October 24, 2026