Compute

A pre-paid digital energy token for Bitcoin SV applications.

April 2026


Abstract

Compute is the first token defined under the Digital Energy Protocol (DEP). It is denominated in fixed satoshi units that correspond directly to the cost of placing data on the Bitcoin SV chain. One Compute token is backed by exactly 500 satoshis of locked BSV, and its sat value scales linearly (1,000 sats = 2 Compute, 125 sats = 0.25 Compute). Each app using Compute picks its own sub-unit structure for internal accounting. Compute is permissionless — anyone with BSV may mint Compute by following the format — and applications consume Compute by burning it as part of an on-chain transaction. This whitepaper specifies the denomination, spending, and burn rules that wallets follow to share a single Compute economy.


1. Why Compute

Application-layer activity on BSV pays miner fees per transaction in satoshis. Compute exists to wrap that raw-satoshi pricing into a form users can reason about.

  1. Cognitive overhead. Users do not natively reason about satoshis, and per-action costs in raw sats fluctuate with BSV's price.

  2. Compute resolves this. One Compute = 500 satoshis — a fixed-size unit of prepaid digital work. Users buy Compute, spend Compute, and watch their Compute balance; they don't need to know the satoshi pricing underneath.

  3. Consumable utility token. Compute is digital energy that fuels on-chain work. It is not money, currency, or an investment instrument. A user buys Compute the way they buy electricity or cellular data: as prepaid capacity for specific activities, not as a store of value or medium of exchange. This makes Compute straightforward to acquire, without the regulatory constraints that attach to money or securities.


2. Denomination

Compute has exactly one invariant:

1 Compute = 500 satoshis

That conversion is fixed forever. It is the only rule every Compute-using application has to agree on.

2.1 Denomination scales linearly

A Compute output's value in Compute is simply its sat value divided by 500. A 500-sat output is 1 Compute. A 1,000-sat output is 2 Compute. A 125-sat output is 0.25 Compute. A 7,250-sat output is 14.5 Compute. Every Compute-aware wallet reads them the same way.

2.2 Sub-unit structure is per-app

Wallets may split Compute into sub-unit fragments inside their own ecosystem to match the per-action pricing their app needs. KeyChat picks 125 satoshis as its sub-unit — 4 sub-units per Compute, one per on-chain message. A different app might pick 250 sats, 100 sats, 50 sats, or any other value that fits its accounting.

Sub-unit amounts can technically be transferred between apps — the token requires only envelope + P2PKH + positive sat value (§3); it does not require values to be whole Compute (multiples of 500 sats). But a receiving app whose sub-unit structure doesn't align with the sender's may end up holding a value its wallet can't cleanly integrate into its own accounting. For that reason, cross-app transfers are recommended in whole-Compute amounts (multiples of 500 sats) — every DEP-aware wallet can absorb a 500-sat multiple without worrying about sub-unit alignment.

2.3 Sat-Compute equivalence

The token does not define a fluctuating exchange rate. One Compute is always exactly 500 satoshis, forever. Applications converting between Compute and fiat (or BSV) use a price oracle of their choosing; the on-chain unit does not vary. Changing unit_sats would silently alter the amount of digital energy locked behind every Compute in every wallet — that is the exact property the invariant is designed to prevent.


3. Format

Per DEP, a Compute output is a P2PKH locking script prefixed with the Compute inscription envelope, locking a positive number of satoshis:

OP_FALSE OP_IF "Compute" OP_ENDIF OP_DUP OP_HASH160 <hash160> OP_EQUALVERIFY OP_CHECKSIG

In hex (with the 7-byte tag 43 6f 6d 70 75 74 65):

00 63 07 43 6f 6d 70 75 74 65 68 76 a9 14 <20-byte hash> 88 ac

Total locking-script length: 36 bytes (vs. 25 for plain P2PKH). The tag adds 11 bytes of permanent on-chain weight per Compute UTXO.

A wallet recognizes a UTXO as Compute if and only if:

  1. The output's locking script begins with the exact byte sequence 00 63 07 43 6f 6d 70 75 74 65 68 (OP_FALSE OP_IF "Compute" OP_ENDIF).
  2. The bytes immediately after the envelope form a standard P2PKH (76 a9 14 <20 bytes> 88 ac).
  3. The output locks a positive number of satoshis.

Outputs that match all three clauses at any denomination are Compute; whether a given app's wallet can cleanly integrate an arbitrary denomination depends on that app's sub-unit structure (§2.2). Outputs that carry a conforming value but lack the Compute envelope are not Compute under any interpretation.


4. Spending and Burning

Compute UTXOs are spent like any P2PKH — a standard <signature> <public-key> unlock, per DEP. A holder can transfer Compute to another holder by producing a new Compute-enveloped output of the same sat value to the recipient's key and paying the miner fee from a separate BSV input, so the denomination is preserved. Verified on BSV mainnet by tx 44cda7e0… (500-sat Compute transferred holder-to-holder, 462-sat BSV input covering the 39-sat miner fee).

How an application constructs its transactions (which UTXOs to select, what outputs to produce, how to allocate sats) is up to that application. This section specifies only the token-level rules every Compute-consuming app must follow.

4.1 Burn semantics

A burn is any transaction that consumes Compute inputs — at any denomination, whole or sub-unit — and does not produce Compute outputs of equivalent sat value. The unwrapped sats are no longer Compute; they flow into whatever non-DEP outputs the tx produces, or to the miner as fee. Verified on BSV mainnet by tx 46d1ee8d… (500-sat Compute burned to 480 sats plain BSV + 20 sats miner fee).

There is no separate burn fee. The tx pays the normal BSV miner fee sized by its bytes, like any other transaction. A bare burn (single Compute input, unwrapped sats land in a single plain P2PKH output) is ~20 sats of miner fee. A burn that also writes OP_RETURN data or produces multiple outputs pays proportionally more — whatever the tx's byte size × 100 sats/KB works out to. The miner doesn't distinguish a burn from an ordinary spend; they charge for bytes.

4.2 Valid change

Change must be re-wrapped and should be cleanly divisible. When a Compute UTXO is spent and the sender wants to retain part of its value as Compute, the change output has to (a) carry the Compute inscription envelope (§3) on its locking script and (b) have a sat value that should be a positive multiple of the producing app's sub-unit (§2.2). Both rules matter for avoiding dust:

Re-wrapping the change at a conforming denomination is the best way to keep the remaining value cleanly-spendable Compute. Verified on BSV mainnet by tx 826dcb04… (1000-sat Compute partially burned: 500 sats re-tagged as Compute change + 480 sats released as plain BSV + 20 sats miner fee).

Applications can route leftover value anywhere they like — plain P2PKH outputs, OP_RETURN, miner fee — but only outputs that carry the full Compute envelope (OP_FALSE OP_IF "Compute" OP_ENDIF + P2PKH, per §3) count as Compute going forward.

4.3 Making exact change (recommended)

Apps can avoid leaving stuck dust by sizing burns to valid sub-unit boundaries. Given a transaction that needs needed_sats of the input's value to cover miner fee plus any non-Compute outputs (operator fees, recipient payments, etc.), and a producing-app sub-unit sub_unit (KeyChat picks 125; other apps pick their own per §2.2):

sub_units   = ceil(needed_sats / sub_unit)
burn_sats   = sub_units × sub_unit
change_sats = total_input − burn_sats

Precondition: the spender has already selected enough input so that total_input ≥ burn_sats. UTXO selection is outside the algorithm's scope.

The app then produces:

Following this pattern keeps every Compute UTXO a clean denomination at all times. Users accumulate no stranded dust; the wallet stays tidy. More broadly, it keeps satoshis circulating on chain rather than stuck as dust.


5. Application-Layer Boundaries

Compute defines the token format (the Compute inscription envelope on a P2PKH locking script) and the unit (500 satoshis per 1 Compute) and the spend/burn rules. It does not define:

Any Compute UTXO produced by one app is spendable by another as long as the receiving app's wallet recognizes the tag. For cross-app transfers, whole-Compute amounts (multiples of 500 sats) are recommended because every DEP-aware wallet can absorb them without needing to align on the sender's sub-unit structure. Sub-unit amounts can be transferred technically but may land as off-denomination fragments in the receiving wallet.


6. Conclusion

Compute is a minimal, sat-backed, permissionless token that gives applications a stable unit of on-chain digital energy. The denomination and spending rules keep Compute UTXOs at usable denominations; leftover fragments get absorbed back into ordinary BSV circulation rather than stranded as dust.


References

Mainnet verification