Technical Implementation

FIRE and ICE are implemented using the Charms protocol - a zkVM-based programmable asset system built on Bitcoin and Cardano. This page explains what Charms is, how it works, and exactly how Alchemy uses it to enforce reserve mechanics on-chain.

What is Charms?

Charms is a programmable assets protocol for Bitcoin (and beyond). Put simply, charms are programmable tokens on top of Bitcoin UTXOs - but with full app contract logic, ZK proof verification, and cross-chain portability. No bridges. No wrappers. No trusted third parties.

A single charm is a token, NFT, or instance of arbitrary app state. Structurally, it is an entry in a mapping of app → data living on top of a Bitcoin UTXO. Multiple charms can coexist on the same UTXO, creating composable strings of programmable state.

Charms is inspired by Ordinals and Runes but goes further: it adds full programmability via ZK-provable app contracts written in mainstream languages (Rust), and it deploys those assets natively on other chains - including Cardano - under their standard token formats (CNTs, ERC-20, SPL) without any bridging infrastructure.

Backed by

Draper Associates

Live product

eBTC Bridge

Ecosystems

Bitcoin, Cardano

Wallet users

3,000+

charms.dev github.com/CharmsDev/charms Whitepaper

How Charms Works

Three innovations combine to make programmable Bitcoin assets possible.

eUTXO Architecture

Charms builds directly on Cardano's pioneering extended UTXO model. Each transaction output can carry multiple assets and arbitrary programmable data. Charms are entries in an app → data mapping attached to a UTXO - you can have as many charms per output as you need, and they travel with Bitcoin-level ownership guarantees.

Bitcoin Metaprotocols

Inspired by Ordinals and Runes, Charms creates fully native digital assets using client-side validation. Every Charms transaction contains a "spell" encoded in an OP_RETURN output. Spells are client-side validated - nodes choose to interpret or ignore them, and double-spending is still prevented by Bitcoin itself.

zkVM Technology

Charms app contracts are Rust functions compiled to a zero-knowledge virtual machine. Each spell carries a Groth16 ZK proof attesting to its correctness - that the app contract logic was satisfied. The proof is compact and verifiable by anyone, including on-chain validators on Cardano, without re-executing the logic.

Spells - Charms Transactions

Every Charms transaction contains a spell - Charms-related metadata stored in an OP_RETURN output, encoded as a CBOR-encoded (NormalizedSpell, Proof) tuple. The proof is a Groth16 ZK proof attesting to the correctness of the spell.

A spell is correct if and only if: it is successfully parsed, it makes sense for the transaction (no more charm outputs than Bitcoin outputs), and it carries a valid ZK proof. Correct spells can mint, burn, and transfer tokens. Incorrect spells are simply ignored.

Spell structure (simplified)

version: 11
tx:
  ins:
    - <input_utxo_txid:vout>       # UTXOs being spent
  outs:
    - 0:                           # output 0 carries charm for app[0]
        ticker: FIRE
        amount: 1000
    - 1:                           # output 1 carries charm for app[1]
        ticker: ICE
        amount: 500
app_public_inputs:
  t/<identity>/<vk>:               # FIRE app contract (token type)
    reserve_ratio: 4.2             # public input to ZK proof
  t/<identity>/<vk>:               # ICE app contract

App Contracts

Each asset type is governed by an app contract - a Rust function that defines the rules for minting, burning, and transferring. This function is compiled to a zkVM, and a Groth16 proof is generated off-chain. Anyone can verify the proof; no one can fake a compliant spell without satisfying the contract.

App contract signature (Rust)

pub fn app_contract(
    app: &App,         // identifies the asset (tag, identity, vk)
    tx:  &Transaction, // the full transaction context
    x:   &Data,        // public inputs (e.g. current reserve ratio)
    w:   &Data,        // private witness (e.g. vault BTC balance)
) -> bool

The predicate must return true for the spell to be valid. If all app contracts in the spell are satisfied, and all prerequisite transactions had correct spells, the spell is accepted and the resulting charms are minted or transferred.

Charms on Cardano

The charms-cardano repository implements Charms as Cardano Native Token smart-contracts, written in Aiken in collaboration between the Charms and Sundial teams.

Main Validator	Routes validation to the appropriate versioned script. Upgradeable by design - new proving systems can be added without breaking existing tokens.
Groth16 Validator	Verifies zkSNARK proofs using the Groth16 proving system. Trustless - no ICP verifiers, no multisig, just math. This is the validator Alchemy targets.
Scrolls Validator (V1)	Initial version using ICP (Internet Computer) verifiers for signature-based approval. Useful for early deployment before Groth16 is fully optimized.
Beacon Token Minting Policy	Manages beacon tokens that enable on-chain discoverability and verification of the delegated validators.

charms-cardano on GitHub docs.charms.dev

How Alchemy Uses Charms

Charms is the execution layer that makes Alchemy's reserve constraints enforced - not promised.

FIRE and ICE as Charms Tokens

FIRE (BTC+) and ICE (BTC−) are implemented as Charms tokens, derived from Bitcoin-native app contracts. Once beamed to Cardano, they are standard Cardano Native Tokens, compatible with every Cardano wallet and DEX from day one.

Reserve Rules as App Contracts

The minting and redemption logic for FIRE and ICE is encoded as Charms app contracts (Rust). The contract checks: Is the reserve ratio above 4.0× before minting ICE? Is it above 4.0× before minting FIRE? Is the reserve zone allowing redemption? These rules cannot be bypassed - they are enforced by the ZK proof.

ZK Proof as On-Chain Enforcement

When a user wants to mint or redeem, the Charms prover generates a Groth16 proof off-chain that all reserve constraints were satisfied. This proof is embedded in the transaction spell. Cardano's Charms-Cardano Groth16 validator verifies the proof on-chain before allowing the CNTs to be minted or burned.

Cardano-Native, No Bridges

FIRE and ICE are created on Cardano as CNTs through the Charms beaming mechanism. The BTC stays on Bitcoin; the token logic runs on Cardano. This is "chain agnostic" in the Charms sense, and it's purely user-run software.

Technical Stack

Bitcoin Reserve custody	Sundial's Hacken-audited BTC lockers hold the shared vault BTC. Bitcoin's UTXO model provides base-layer security; no custodian, no bridge trust assumption.
Charms Protocol Token logic & reserve enforcement	FIRE and ICE app contracts written in Rust define minting, burning, and redemption rules. Each spell carries a Groth16 proof that reserve constraints were satisfied before state changes occur.
Charms-Cardano On-chain verification	Aiken validators deployed on Cardano verify ZK proofs trustlessly via the Groth16 validator. A main routing contract delegates to versioned validators, with beacon tokens for on-chain discoverability.
Cardano Native Tokens FIRE and ICE token lifecycle	FIRE and ICE live as CNTs (Cardano Native Tokens) on Cardano, making them compatible with every Cardano wallet, DEX, and application without bridging or wrapping.