A permissionless token convention for Bitcoin SV
April 2026
The Digital Energy Protocol (DEP) defines a minimal convention for issuing fungible tokens directly on the Bitcoin SV ledger without requiring an issuer, a covenant, or a side-database. The protocol's central idea is that a token is satoshis locked to a named class — a DEP token output locks a positive quantity of satoshis behind an inscription tag prefixed onto an otherwise standard pay-to-public-key-hash (P2PKH) output. The locked satoshis represent stored on-chain work capacity — digital energy. A holder may transfer the token to another holder (spend a DEP output and produce a new DEP output). Applications use DEP tokens by burning them — the unwrapped sats fund the on-chain work the application is performing. Tokens are not a payment rail; they are prepaid capacity, redeemed by burning. Authenticity has two layers: DEP-level format match — any output whose locking script matches the protocol's inscription envelope (tag + P2PKH) and locks a positive quantity of satoshis is format-valid DEP — and token-level validity, which is whether that DEP output's sat value conforms to the token's own sat-locking rules (defined per-token, not by DEP itself). There is no minting authority; anyone may lock sats into a DEP token by following the format. DEP imposes no on-chain consensus rules beyond what BSV already enforces.
BSV permits arbitrary script structures, large data payloads, and unbounded throughput. These properties make BSV the natural substrate for token systems that don't require an external state machine. Existing BSV token protocols typically introduce one or more of:
DEP takes the opposite design stance. The protocol asserts no consensus, designates no issuer, and embeds no enforcement logic. A DEP token is satoshis locked to a named class by an inscription tag placed in the locking script. The tag says "this output is a Compute token" (or whatever name the token designer chooses), and the sats behind it can only be released — unwrapped back to ordinary BSV — by burning the token. The locking script is permanently committed on chain when the output is created. Authenticity is decided by anyone reading the chain in two layers: at the DEP layer, the script must match the envelope template and the output must lock a positive quantity of sats; at the token layer, that locked value must conform to the token's sat-locking rules (defined per-token, not by DEP itself). Anyone may define a new token class by picking a name and declaring its sat-locking rules, then following the envelope format.
DEP treats satoshis as units of digital energy — stored capacity for on-chain work. Satoshis in a UTXO can be spent to produce transactions; transactions consume block-space that miners charge for in satoshis. In this sense, sats are what on-chain activity runs on.
A DEP token is satoshis wrapped in a named envelope. Wrapping locks the sats to the token class; unwrapping (burning) releases them back to ordinary BSV.
DEP imposes no protocol-level fees. Minting, sending, and burning each cost only the ordinary BSV miner fee for the underlying transaction — the same fee any BSV spend would pay. There is no mint tax, no burn tax, no transfer royalty. Where the miner fee comes from depends on the operation (detailed per operation below), but DEP adds nothing on top.
To burn a DEP token is to spend the output without producing a new DEP output of the same class. The sats are no longer wrapped in a DEP envelope; they're ordinary BSV again, spendable anywhere the spender directs them. The token identity is extinguished.
As with any BSV transaction, the burn tx pays a miner fee. The holder chooses where that fee comes from: out of the unwrapped sats themselves (the holder recovers the difference as plain BSV) or from a separate BSV input alongside the DEP input.
This framing is what makes DEP more than a tagging scheme:
An application that consumes a DEP token does so by burning it as part of a transaction that performs the application's work. The unwrapped sats fund the digital-energy-related activity — the bytes the application writes on chain — along with whatever auxiliary outputs that activity requires (operator fees, miner fees, etc.). The reference application, KeyChat, burns a Compute token to send a message; the unwrapped sats cover the message transaction's miner fee, a recipient dust output, and a small operator fee.
A DEP-tagged output is a standard Bitcoin transaction output with two fields: a value (the satoshis locked into the output) and a locking script (the conditions under which the sats can be spent). The DEP convention lives in the locking script:
Output = {
value: <N satoshis> ← sats locked to the token class
script: OP_FALSE OP_IF <token-name> OP_ENDIF <standard P2PKH>
}
The script in hex:
00 63 <pushdata-length> <token-name-bytes> 68 76 a9 14 <hash160> 88 ac
│ │ └── inscription tag ─────────────┘ │ └── standard P2PKH ──┘
│ │ │
└── OP_FALSE OP_IF └── OP_ENDIF
Together, the value and the inscription tag say: "these N satoshis are a <token-name> token, spendable by the key whose hash is <hash160>." Locking the sats happens because they cannot be spent without satisfying the P2PKH — and anyone reading the chain sees the tag prefixed to that P2PKH, identifying them as a token of that class.
The OP_FALSE OP_IF ... OP_ENDIF envelope is a no-op branch: BSV's script interpreter pushes 0 on the stack, sees the OP_IF evaluate false, and skips to OP_ENDIF. The inscription bytes inside the branch are never executed. They occupy space in the locking script but contribute nothing to spend conditions. After OP_ENDIF, the standard P2PKH template (OP_DUP OP_HASH160 <20-byte hash> OP_EQUALVERIFY OP_CHECKSIG) is what actually authorizes the spend.
The token name is an arbitrary byte string — typically ASCII ("Compute", "Energy", "Tokens") but binary is permitted.
The DEP envelope is part of the locking script, committed to on chain the moment the token is minted. On-chain data is immutable — no operation can modify the locking script of an existing DEP output. A holder cannot "peel off" the envelope while keeping the sats locked to the token class.
A DEP token's entire lifecycle stays within three operations:
The envelope is either present (the sats are a DEP token) or absent (the sats are ordinary BSV). There is no third state — nothing that would let a DEP token become "untagged" while retaining its identity.
To spend a DEP-tagged output, the spender provides a standard P2PKH unlocking script: <signature> <public-key>. Because the inscription branch is skipped at runtime, no special unlocking logic is required. At the Bitcoin script level, a DEP output spends exactly like a regular P2PKH output. The inscription envelope is what DEP-aware wallets and indexers read to identify the token class; the Bitcoin interpreter itself ignores it.
Beyond the script level, the transaction's structure determines whether a spend is a send (lock preserved) or a burn (lock released):
Send — the sender builds a transaction with two inputs and at least two outputs:
The DEP output preserves its exact denomination because the miner fee is paid entirely from the separate BSV input — the sats locked to the token class never leak. Verified on BSV mainnet by tx 44cda7e0… (500-sat Compute transferred holder-to-holder with 462-sat BSV input covering the 39-sat miner fee).
Burn — the spender builds a transaction with:
The unwrapped sats flow into whatever outputs the transaction specifies (minus miner fee). If no separate BSV input covers the fee, the fee comes out of the DEP sats themselves. Verified on BSV mainnet by tx 46d1ee8d… (500-sat Compute burned to 480 sats plain BSV + 20 sats miner fee).
A spender may consume a DEP-tagged input and retain part of its value as the same token by producing a new DEP-tagged output of the same class at a smaller sat value — a partial burn with re-wrapped change. The retained portion must carry the envelope. Any output that lacks the envelope is ordinary BSV regardless of its sat value, even if the sats originated from a DEP-tagged input and even if the value happens to match a valid token denomination. Token identity is never inherited implicitly through a spend; it requires an explicit envelope on every output that should remain in the class. This is a direct consequence of §3.1's "envelope either present or absent, no third state" rule. 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).
DEP requires that the retained portion lock a positive quantity of satoshis inside the envelope (inscription tag + P2PKH) — otherwise there is no token, just an empty tag. Beyond that, DEP imposes no specific denomination rules; the exact sat amounts that count as valid instances of a given token are the token's own concern, defined in its spec. A change output that meets the DEP envelope-plus-locked-sats requirement is format-valid DEP; whether its sat value makes it a usable instance of the named token is determined by that token's own denomination rules, which each token documents (and enforces in its wallets) for its own reasons — typically to keep the wallet free of stuck dust.
DEP makes no claim about who minted a given token. Anyone with the ability to construct a transaction can produce a DEP-tagged output. Two consequences follow:
Address-based lookups (the primary way wallets discover their UTXOs) traditionally match the locking script against known templates. A DEP-tagged output deviates from the standard P2PKH template and will not be returned by a naive address → UTXOs query unless the indexer is updated to recognize the envelope.
The required indexer change is small and generic. For any locking script matching:
^00 63 [pushdata bytes] 68 76 a9 14 [20-byte hash] 88 ac$
— extract the [20-byte hash] and index the output under the corresponding base58 address. The output becomes addressable like any standard P2PKH while preserving its DEP tag in the script body.
This is a one-time, vendor-agnostic update applicable to any inscription-tagged P2PKH protocol, not just DEP.
DEP is not a smart-contract platform, a token registry, or a federation. It is a convention for locking satoshis to named token classes via a no-op inscription envelope on standard P2PKH outputs. The satoshis inside those outputs represent stored on-chain work capacity — digital energy that the holder has committed to a token class and may release at any time by burning. Because the tokens are the energy, Bitcoin's own conservation and redeemability properties apply directly — DEP doesn't have to implement them separately: no reserve to manage, no issuer to trust, no side-database to synchronize.
The Compute token, defined in the companion whitepaper, is the first token under DEP and serves as prepaid digital energy for the KeyChat messaging application.
44cda7e0… — 500-sat Compute transfer, holder-to-holder, denomination preserved (§3.2).46d1ee8d… — 500-sat Compute full burn to plain BSV (§3.2).826dcb04… — 1000-sat Compute partial burn with re-tagged change (§3.3).