Skip to main content
Alchemy is a product in its own right, not a rail. It takes one reserve of BTC and issues two complementary claims against it: FIRE and ICE. It is built on Sunbeam and Charms, and is sold alongside the Yield Marketplace.
Alchemy is in development. See Status and security.

​
The Reserve Structure

Alchemy works by pooling BTC collateral and splitting the economic exposure into two tranches. The same reserve backs both assets simultaneously.
  • ICE holders have a senior claim on the reserve. When Bitcoin’s price falls, ICE is protected first.
  • FIRE holders have a junior claim. They absorb downside before ICE holders are affected, but they also capture amplified upside when Bitcoin appreciates.
The reserve ratio: the value of pooled BTC relative to outstanding ICE liabilities: governs when each asset can be minted or redeemed. The design enforces these thresholds on-chain with a zero-knowledge proof.

​
FIRE and ICE Compared

FIRE is the junior reserve-growth asset. It is designed for investors who want amplified exposure to Bitcoin price appreciation and are comfortable absorbing downside volatility first.Formula: FIRE = (V · P − L) / N_fireWhere V is the vault BTC volume, P is the Bitcoin price, L is the total ICE liability, and N_fire is the number of outstanding FIRE tokens.FIRE holders benefit when BTC appreciates because the reserve surplus: after ICE liabilities are fully covered: flows entirely to FIRE. In a declining market, FIRE’s value contracts before ICE holders are affected.
ICE is not a short on Bitcoin. It is the senior tranche of a Bitcoin-collateralized reserve. If you want stable, USD-denominated exposure backed by BTC, ICE is designed for you. If you want amplified BTC growth, FIRE is the junior tranche that captures that upside.

​
How Reserve Constraints Are Enforced

In the design, the reserve rules are enforced by Charms app contracts and a proof, not by an admin key:
1

Reserve rules encoded as Charms app contracts

The minting and redemption logic for FIRE and ICE is written as Rust functions compiled to a zero-knowledge virtual machine. The contract checks conditions like: Is the reserve ratio above 4.0× before minting ICE? Is the reserve zone allowing FIRE redemption? These rules are part of the proof statement.
2

Off-chain prover generates a Groth16 proof

When you want to mint or redeem, the Charms prover runs the app contract off-chain and generates a compact Groth16 zk-SNARK proof attesting that all reserve constraints were satisfied. This proof is embedded in the transaction spell.
3

On-chain validator verifies the proof

The staking_groth16 Plutus v3 validator verifies the Groth16 proof using BLS12-381 pairings as native builtins. If the proof is invalid: meaning the reserve constraints were not satisfied: the transaction is rejected at the ledger level.
4

Native tokens are minted or burned

Only after the proof passes does the ledger mint FIRE or ICE as native tokens on the settlement layer. These tokens are then fully compatible with every wallet, DEX, and application on the settlement layer from the moment of minting.

​
Technical Stack

Alchemy is built on three layers that work together:

Bitcoin

Sundial’s audited BTC lockers hold the shared reserve on Bitcoin.

Charms Protocol

FIRE and ICE app contracts written in Rust define every minting, burning, and redemption rule. Each spell carries a Groth16 proof that reserve constraints were satisfied before state changes occur.

Charms Validators

The main routing contract and staking_groth16 validator verify the proofs on the L1 with BLS12-381 pairings. Beacon tokens make validators discoverable on-chain.

​
Reserve Scenario Simulator

You can explore how FIRE and ICE respond to different BTC prices and reserve ratios using the interactive visualizer at sundialprotocol.com/alchemy/visualizer. Move the sliders to see how reserve ratios shift, when redemption thresholds are crossed, and how FIRE value responds to price changes at different collateralization levels.
The visualizer is the quickest way to understand the reserve zones. Try a 20% BTC price drop near the 4.0× threshold and watch how each claim responds.

​
Market Precedent

FIRE and ICE are not novel in concept: they follow a category of Bitcoin reserve and yield products with established demand. sundialprotocol.com/alchemy/market-precedent covers how STRC, Pendle, Djed, and Ethena validated demand for this product category and how Alchemy differentiates from each.

​
Frequently Asked Questions

Common questions about FIRE and ICE: including how redemptions work, what happens in a black-swan price crash, and how the reserve ratio is measured: are answered at sundialprotocol.com/alchemy/faq.
In theory, yes. If the BTC price falls sharply enough that V · P ≤ L: the reserve’s USD value equals or drops below total ICE liabilities: then FIRE’s formula produces zero or a negative value. In practice, FIRE redemptions are suspended below a 4.0× reserve ratio, which provides a wide buffer before this scenario is reached. ICE redemptions remain available down to 2.0×.
ICE is a USD-denominated senior claim on a BTC reserve, not a fiat-backed or algorithmic stablecoin. Its value is formulaically derived from the reserve ratio and BTC price. If the reserve ratio falls below 2.0×, ICE redemptions halt. ICE is not pegged; it is a structured product with defined priority in the reserve.
In the design, the reserve is held in Bitcoin scripts built with Sundial’s btc-locker library. See Dawn for how those scripts work.