Bitcoin metaprotocol · protocol tag 1

Alkanes

Alkanes puts WebAssembly smart contracts over Bitcoin. Token balances are carried as protorunes inside protostones, and a protostone rides inside a runestone in an OP_RETURN output. Bitcoin stores the instructions; an indexer replays every block and derives the resulting state.

Payload encoding Encode or decode a protostone

The same skeleton every alkanes transfer has. The double bond at the left is the 6a 5d envelope; without it there is no protostone at all.

Chain: Bitcoin
Network: mainnet from block 880,000
Protocol tag: 1
Carrier: OP_RETURN runestone
Implementation: alkanes-rs 2.2.1-rc.4
Lifecycle: Experimental

Read this before you build a transfer

An alkanes transfer payload is an encoded protostone, not JSON. The script must begin 6a 5d: OP_RETURN followed by OP_PUSHNUM_13. A plain 6a OP_RETURN carrying JSON, text, or any other blob is not a runestone, so alkanes-rs never reads a protostone out of it. The indexer only moves and clears protorune balances when it finds real protostones, so a wrong payload does not fail loudly: the transaction confirms, the fee is spent, and the asset stays where it was in the index while the UTXO that held it is gone.

Read the encoding page, or check a script hex in the decoder.

What Alkanes is, in plain language

Bitcoin transactions cannot run programs. Alkanes works around that the way every Bitcoin metaprotocol does: the transaction carries an instruction, and software outside Bitcoin agrees on what that instruction means.

The instruction lives in an OP_RETURN output. It is a runestone, the same envelope the Runes protocol uses, extended with a field that carries protostones.
A protostone names a sub-protocol. Alkanes is sub-protocol number 1. A protostone can move balances (edicts), or carry a message (calldata) for the sub-protocol to execute.
Contracts are real WebAssembly. A contract binary is deployed in a transaction witness. Calls to it are messages inside protostones. The contract runs in a metered, sandboxed wasmi VM with no network, no filesystem, and no source of randomness.
Balances follow Bitcoin's UTXO model. An alkane balance is attached to a specific transaction output. Spending that output is what lets a transaction move the balance.
State is derived, not stored on chain. Every indexer that replays the same blocks with the same rules reaches the same state. There is no alkanes chain and no alkanes network token.

Who this documentation is for

Wallet and app developers

Build a payload that works

The encoding page gives the exact byte layout with worked examples, and the guide walks through deploy, execute, and transfer.

Protocol implementers

Match the reference behaviour

The specification gives numbered rules with the alkanes-rs source path for each, and the test vectors pin down the edge cases.

Holders and analysts

Understand what you are looking at

The reference covers terminology, indexer semantics, reorg behaviour, and what Bitcoin Universe products do and do not support today.

How a transaction carries alkanes

A protostone also occupies a virtual output. For a transaction with N real outputs, the first protostone sits at index N+1, the second at N+2, and so on. Edicts can target those virtual indexes to hand balances to a protostone before its message runs.

Support in Bitcoin Universe products

Only verified support is listed. Everything else is stated as unsupported rather than implied.

From the Core protocol registry and the ecosystem capability snapshot.
Capability	State	What that means
View alkanes and activity in Core	Supported	Discovery actions only: view, discover, view collection, view activity, view transaction.
Wallet view, send, receive	Supported	Declared wallet actions for the alkanes protocol in the Core registry.
Inscribe: mint	Supported	The only inscribe action declared for alkanes.
Core marketplace trading	Read-only	Marketplace availability is `read-only`. List, update listing, unlist, buy, make offer, accept offer, cancel offer, sell, settle, and reconcile are all unsupported.

Recorded reason, verbatim

“Alkanes mutations remain read-only until exact Alkane state, transferability, builder, signed-transaction validation, broadcast, settlement, and reorg recovery are deployed and proven.”

That single reason is recorded against every unsupported marketplace action. The snapshot also records that no executable order authority and no executable settlement authority are deployed, that freshness is not enforced, and that no supported mutation reaches confirmation or settlement.

Entry points

Payload encoding

The byte layout of a protostone, from integers to LEB128 to 15-byte chunks to script, with a full worked example you can verify byte by byte.

Specification

Numbered normative rules: envelope, protocol tag, edict semantics, cellpacks, execution, state transitions, validity and invalidity.

Guide

Deploy a contract, execute a call, transfer a balance. Worked transactions and the support matrix.

Reference

Terminology, indexer semantics through metashrew, confirmation, reorg, mempool, fees, limits, security, and an implementation checklist.

Test vectors

Valid and invalid vectors with expected outcomes, derived from the encoder and from alkanes-rs behaviour.

Protostone tool

Encode an edict into script hex, or paste a script hex and see exactly what an indexer reads out of it. Runs entirely in your browser.

Origin and attribution

Alkanes did not originate at Bitcoin Universe. The protocol and its reference Rust implementation come from the upstream kungfuflex/alkanes-rs project, which also hosts the protocol wiki, and Alkanes is built as a sub-protocol of protorunes, which is itself a sub-protocol extension of Runes. Runes originated outside this organisation as well.

bitcoinuniverseio/alkanes-rs is this organisation's implementation repository and is the source every statement on this site is checked against. Where Bitcoin Universe makes its own indexing or product decisions, this documentation says so explicitly.