> ## Documentation Index > Fetch the complete documentation index at: https://docs.sundialprotocol.com/llms.txt > Use this file to discover all available pages before exploring further. # Alchemy: FIRE and ICE Bitcoin-Backed Reserve Assets > Alchemy issues two claims against one BTC reserve: ICE, a senior USD-denominated claim, and FIRE, a junior claim that takes the volatility and the upside. 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](https://docs.sundialprotocol.com/products/sunbeam.md) and Charms, and is sold alongside the [Yield Marketplace](https://docs.sundialprotocol.com/products/yield-marketplace.md). > [!NOTE] > > Alchemy is in development. See [Status and security](https://docs.sundialprotocol.com/overview/status.md). ## 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 (junior)** 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_fire` Where `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. | Property | Value | | - | - | | Claim priority | Junior: absorbs volatility first | | Price exposure | Higher-beta BTC appreciation | | Liquidation risk | None: no margin calls | | Redemption threshold | Reserve ratio above 4.0× | | Minting threshold | Reserve ratio above 4.0× | 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 (senior)** ICE is the senior BTC-backed claim. It is designed for investors who want USD-denominated exposure to Bitcoin-backed yield with lower volatility: stability-seeking participants in the reserve structure. **Formula:** `r = (V · P) / L` Where `r` is the reserve ratio, `V · P` is the USD value of pooled BTC, and `L` is the total ICE liability. | Property | Value | | - | - | | Claim priority | Senior: protected from downside first | | Price denomination | USD-denominated | | Volatility profile | Lower: protected by reserve buffer | | Redemption threshold | Reserve ratio above 2.0× | | Minting threshold | Reserve ratio above 4.0× | ICE is not a short position on Bitcoin. It is the **senior claim in the reserve**: if BTC falls significantly, ICE holders are covered first from the remaining collateral. The reserve ratio must stay above 2.0× for redemptions, providing a substantial buffer before ICE is at risk. > [!NOTE] > > 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](https://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. > [!TIP] > > 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](https://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](https://sundialprotocol.com/alchemy/faq). > **Can FIRE go to zero?** > > 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×. > **Is ICE a stablecoin?** > > 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. > **Who holds the BTC collateral?** > > In the design, the reserve is held in Bitcoin scripts built with Sundial's `btc-locker` library. See [Dawn](https://docs.sundialprotocol.com/products/dawn.md) for how those scripts work. > **How are FIRE and ICE related to Sunbeam?** > > FIRE and ICE are designed as Charms tokens. The BTC stays on Bitcoin, and the reserve constraints are checked on the L1 by the `staking_groth16` validator. Once issued, FIRE and ICE are native tokens on that ledger. See [Sunbeam](https://docs.sundialprotocol.com/products/sunbeam.md) for how beaming works. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.