Charms

Charms

A zero-knowledge token protocol whose spells state the resulting charms in the clear; it moved from witness to OP_RETURN, and its Bitcoin-side supply is a lower bound.

Charms 0.01 % of the chain's bytes in Book A, as of block 972,299, 2026-10-20 09:30:48 UTC

Charms is a zero-knowledge token protocol. In BTI's token table its tokens are Charms, each identified by a charm id, with the note "supply is a lower bound". BTI is its indexer: it is a native protocol, read by BTI's own charms decoder.

How Charms writes to Bitcoin #

BTI's Charms attribution study (2026-08-04) rests on one finding: "the spell states the resulting charms in the clear". A spell is the message that moves charms. A Groth16 proof travels with it and only certifies that the app's own rules were obeyed. So there is no virtual machine to run and no state to fetch: the token layer can be read from block bytes with a parser. The study places Charms alone in a bucket it calls "complete-and-readable", between commitment-only protocols (excluded, because their state lives off chain) and OP_NET (complete, but readable only by executing it).

Spells use two carriers, with one marker:

up to version 8, a taproot witness envelope that opens OP_FALSE OP_IF and pushes spell;
from version 9, an OP_RETURN that pushes spell.

The data-types reference names single-transaction atomicity as one reason a small message chooses OP_RETURN, and lists Charms among them.

A controlled witness-discount measurement #

The study calls the carrier move the roster's cleanest witness-subsidy experiment, because the payload stayed the same while the carrier changed. It recorded that the same spell of about 800 bytes costs 4.16 times more block weight in OP_RETURN than in the witness, against a theoretical floor of 4.00. Protocol-wide bytes per vbyte fell from 2.627 in the witness era to 1.110 in the OP_RETURN era. The ratio stays above 1.0 even then, because Charms transactions still spend inputs whose signatures sit in the witness. See the witness discount.

How BTI attributes its bytes #

The decoder runs in replay mode over both carriers. Some points from the study:

Identity is on the wire. A charm's ref is its app triple, <tag>/<identity>/<vk>, copied verbatim from the spell. The verifying key is part of the identity, so an app that upgrades its code mints a new token. BTI does not merge the two, and keeps the app identity as an alias so the versions can be found together.
The proof is framing. "A zero-knowledge proof is protocol framing, not artifact body": its bytes are carrier span, in Book B, never Book C. The August review confirmed that the decoder declares content 0 for every claim.
Cross-chain leakage. A spell can beam a charm out to Cardano, which lowers Bitcoin-side supply with nothing destroyed, and a charm can arrive with no Bitcoin genesis. The study calls this a fifth decay category. In its words, "Bitcoin-side supply is a lower bound on global supply, not a measurement", and the roster records that the bound is declared unconditionally.
Commits. Each witness-era spell needs a commit transaction, an enabler whose bytes join the spell's Book A only.

Findings of the August review #

The BTI protocol review of 2026-08-29 found 99.56 % of Charms' Book B on riding claims, the largest such share among the native protocols it audited, and that the decoder declares dedicated outputs on riding verdicts, where ruling B30(1)(iii) reserves the funding remainder for dedicated claims. How much of that riding Book B is over-claimed was not measured.

Live figures #

Charms holds 63,321,013 bytes in Book A and 0 in Book C. The books count 28 charms across 82,119 operations, from block 895211 to 971336 (as of block 972,299, 2026-10-20 09:30:48 UTC).

Sources #

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