> ## 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.

# Sunbeam: beaming Bitcoin assets to other chains

> Sunbeam moves Bitcoin-native assets to a destination chain. Built on Charms: the asset is destroyed on Bitcoin and re-created on the destination, authorized by a proof.

Sunbeam is Sundial's beaming product. It moves a Bitcoin-native asset off Bitcoin and onto a destination chain, with a proof carrying the authorization in place of a custodian. It is built on **Charms**, and it is the only route in the Sundial stack that takes assets off Bitcoin.

> [!NOTE]
>
> Sunbeam is on testnet. See [Status and security](https://docs.sundialprotocol.com/overview/status.md).

## What a charm is

A charm is a programmable asset attached to a Bitcoin UTXO. Structurally it is an entry in an `app → data` mapping on that UTXO. Several charms can sit on one UTXO, and each has an app contract that defines how it is minted, burned and transferred.

Every Charms transaction carries a **spell**: metadata in an `OP_RETURN` output, encoded as a `(NormalizedSpell, Proof)` pair. The proof is a Groth16 zk-SNARK that the app contract was satisfied. Anyone can verify it.

## How beaming works

A beam is a pair of spells: a **send** on the source chain and a **receive** on the destination chain.

**1. Prepare a destination**

You create a small placeholder output on the destination chain. This is the exact output the beamed asset will land in.

**2. Send on Bitcoin**

You broadcast a Bitcoin transaction that destroys the charm and commits to the placeholder:

```text theme={null}
commitment = SHA-256(destination_utxo ‖ nonce)
```

The commitment doesn't name an address. It names one output you control on the other chain, plus a nonce you keep. The cross-chain intent is recorded in a confirmed Bitcoin transaction.

**3. Prove finality**

Once the Bitcoin transaction has enough confirmations, a finality proof is assembled: a Merkle proof that the transaction is in a block, plus the block headers that follow it.

**4. Receive on the destination**

The Charms prover takes the finality proof and produces the receive transaction, which spends the placeholder and re-creates the asset there. The prover refuses unless the placeholder and nonce hash to the commitment and the source transaction is proven final.

Finality proofs are specific to the source chain. From Bitcoin it is a proof-of-work proof. From Cardano it is a signed attestation.

## Two verification paths

The receive transaction is authorized on the settlement L1 in one of two ways. A beacon token in the transaction's reference inputs selects which.

**V1: Scrolls (signed)**

A threshold-signing canister on the Internet Computer re-verifies the proof from the raw transaction and signs it. The L1 validator checks that signature.

**Trust:** the signing canister. This is the path that runs on testnet today.

**V2: Groth16 (proof-verified)**

The L1 validator verifies the Groth16 proof itself, using the BLS12-381 pairing builtins of Plutus V3:

```text theme={null}
e(πA, πB) = e(α, β) · e(Σ xᵢ·ICᵢ, γ) · e(πC, δ)
```

**Trust:** no trusted signer. This is Sunbeam v2.

## The L1 validators

Four Plutus V3 scripts handle the destination side on Cardano. The code is in [`charms-cardano`](https://github.com/CharmsDev/charms-cardano).

| Script | Role |
| - | - |
| `main` | A routing validator. It finds the beacon for the requested protocol version and requires that version's validator to run in the same transaction. It holds no application logic. |
| `scrolls` | The V1 validator. Checks the canister's signature. |
| `staking_groth16` | The V2 validator. Reads the spell and proof from the last output, checks the protocol version, and verifies the proof. |
| `free_mint` | The minting policy for the beacon tokens that make each versioned validator discoverable. |

These validators have been independently reviewed, and all findings are resolved. See [Status and security](https://docs.sundialprotocol.com/overview/status.md#audits-and-reviews).

## The first Sunbeam app

The first Sunbeam tBTC app is **service-mediated**: the app contract controls who can change supply, and the bridging service checks the BTC backing before minting. Proof-verified backing is planned.

## Where it leads

* BTC beamed by Sunbeam lands on the [Sundial L2](https://docs.sundialprotocol.com/l2/overview.md).
* [Alchemy](https://docs.sundialprotocol.com/products/alchemy.md) is built on Sunbeam and Charms.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.