# Alkanes

Contract tokens called through protostones inside a runestone. metashrew's trace is the record; every contract that ran claims the bytes.

URL: https://blockspace.wiki/protocols/alkanes/

An [alkane](https://blockspace.wiki/glossary/alkane/) is a token of the Alkanes protocol. BTI's token table calls alkanes "protostone VM tokens" and names each one by its AlkaneId, written `block:tx`. DIESEL is `2:0`.

## How Alkanes puts data on Bitcoin

Alkanes messages are [protostones](https://blockspace.wiki/glossary/protostone/). They ride inside a runestone, in the OP_RETURN output that Runes uses, under the protorunes field, tag 16383. The case studies note that the tag is odd, so plain runes ignores it and never treats it as a [cenotaph](https://blockspace.wiki/glossary/cenotaph/). The data-types reference lists two Alkanes channels: protostones in OP_RETURN, and Alkanes WebAssembly in the witness [envelope](https://blockspace.wiki/glossary/envelope/).

Case 2 of the BTI case studies decodes one carrier. A single 30-byte OP_RETURN holds a rune mint of UNCOMMON•GOODS and a protostone that mints DIESEL. Case 6 shows a runestone with two protostones, the first pointing at the second through a "shadow" output number past the real outputs.

BTI's ruling on protorunes is short: a carrier convention, not to be built, because "the bytes belong to alkanes".

## How BTI attributes the bytes

Alkanes is catalogued by the metashrew adapter, which reads [metashrew](https://blockspace.wiki/glossary/metashrew/). Its trust is "definitional" in the [trust triad](https://blockspace.wiki/glossary/trust-triad/): the indexer table says alkanes.wasm "IS the protocol". A [second-source adapter](https://blockspace.wiki/glossary/second-source-adapter/), alkanes-explorer, extracts the same trace feed independently. It records one row per executed trace for the executing contract only, and writes no bytes.

The carrier bytes alone do not say which contracts ran, whether a call reverted, or what a number means as a call. The trace says it. Per the adapter, every contract whose code ran claims the transaction, plus the alkanes whose balances moved. Net movement decides the operation label: units that came out without coming in are a mint.

The case studies show three shapes:

- **Two protocols, one carrier** (case 2, block 911,180). The rune mint and the DIESEL mint each claim the whole 371-byte transaction. Each is backed by exactly half, 185.5 bytes, and its own message is a separate sub-span of the shared output.
- **Five claimants** (case 5, block 911,180). A DIESEL swap through a router and pool contracts gives five alkanes identical whole-transaction claims. Each takes 90 of the 450 bytes. The case notes that a divisor counting region rows instead of tokens would have been "invisible here in every aggregate except the conservation line" (finding F1 confirmed the shipped function counts tokens).
- **Blocked above the source** (case 6, block 961,190). metashrew stood at 949,716 when the case was studied, 11,474 blocks below the transaction. The bytes were fully measured and claimed by nobody. The answer for a transaction beyond a source's tip is a refusal, not a guess.

Finding F8 adds an operational fact. Because the catalogue pass clamps at the lowest source tip, a lagging metashrew holds back even natively decoded runes in the same transactions. The indexer table calls metashrew "routinely the pass's binding clamp". See [the frontier](/concepts/the-frontier/).

Factory and router calls carry no envelope, so their [Book C](https://blockspace.wiki/glossary/book-c/) is 0. Blockspace Holdings' records list 68 MB of Alkanes content, protostone payloads and WebAssembly, carried in runestone envelopes.

## Live figures

The family's books (as of block 972,299, 2026-10-20 09:30:48 UTC):

| measure | value |
|---|---|
| Book A | 11.95 GB |
| Book C | 0.07 GB |
| share of the chain's bytes (Book A) | 1.54 % |
| share of all Book A bytes | 8.93 % |
| tokens | 104,023 |
| operations | 107,371,036 |
| first height | 880004 |

## Holders

The alkanes holders study (measured 2026-10-19) found the family's weight concentrated. DIESEL alone held 10.99 GB, 92.1 % of the family's Book A. The top 10, 100 and 1,000 tokens held 95.5 %, 98.9 % and 99.9 %.

It rejected two routes. The alkanes-explorer database holds no balances. Replaying metashrew's views would mean reimplementing contract execution, and spent outputs still answered. The chosen route reads metashrew's database as a secondary instance, filters out spent outputs, and then updates per block. That route covered 84,557 tokens holding 99.10 % of the family's bytes, across 60,384 holder scripts. Tokens with no current holder (0.107 GB) are a gap row, "no current holder".

Read on 2026-10-20, the leaderboard's coverage table placed 99.10 % of the family's Book A on 60,421 addresses.

## Not covered by a source

The July 2026 measurement run gives no bytes:vbytes ratio for Alkanes, and no Blockspace Holdings document describes the WebAssembly envelope's layout.

Sources:

- Blockspace Holdings records
- block.space docs: data types · https://block.space/docs/datatypes
- block.space protocols API · https://block.space/api/protocols
- block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage

Live figures: protocols as of block 972,299, 2026-10-20 09:30:48 UTC

Updated: 2026-10-20