Skip to main content
Sundial Protocol is an optimistic rollup that gives BTC and ADA holders high-throughput staking and yield with L1-grade security. This page answers the most common questions across getting started, using the protocol, running infrastructure, and understanding how the system works under the hood.

Getting Started

Sundial is a 7-layer stack built on top of an L1 settlement layer. It combines a Midgard optimistic rollup for high throughput (2,000 to 5,000 TPS), BTC-native staking via the BTC Locker protocol, and trust-minimized bridges that move Bitcoin-native assets cross-chain. Users can stake BTC or ADA, earn yield, and interact with a shared liquidity pool while their funds stay secured by L1 smart contracts.
On testnet you can connect a wallet, claim testnet sBTC from the faucet, stake BTC or ADA, monitor positions in the Portfolio tab, and practice withdrawals. Operators, Watchers, and Facilitators can also participate as network participants. See the Testnet Guide for a walkthrough.
Sundial is currently in testnet on Preprod. Mainnet timing follows successful testnet milestones. Do not send real BTC or ADA to any testnet address.
L1 wallets: Eternl, Lace, Typhon, Yoroi, GeroWallet, and NuFi (any CIP-30 compatible wallet). Bitcoin wallets connect through Reown AppKit. You can connect both at the same time. Full instructions are on the Connect Your Wallet page.

Staking and Yield

Staking BTC uses the BTC Locker protocol: your Bitcoin is locked in a native timelock and escrow script on Bitcoin itself, and a corresponding sBTC position is created on the Sundial L2. Staking ADA deposits your ADA into the Sundial L2 through the settlement contract; funds are then allocated to yield-generating instruments. Both flows are non-custodial.
FIRE and ICE are the two tranches produced by the Alchemy component. A BTC reserve is split into FIRE (junior, high-beta growth exposure) and ICE (senior, USD-denominated). Groth16 zk-SNARK proofs enforce the reserve constraints, and tokens are minted as standard native tokens on L1 after the proof passes.
Rewards accrue in the asset you staked (BTC or ADA) and are visible in the Portfolio tab of the dashboard. See Tokenomics for how fees and rewards flow through the system.

Withdrawals and Exits

ADA withdrawals go through a maturity window equal to the fraud-proof challenge period. Once the window elapses, funds are claimable on L1. If you need funds sooner, a Facilitator can front the liquidity for a small fee. BTC withdrawals are gated by the timelock on the Bitcoin escrow script.
An escape hatch in the L1 contracts lets you exit the L2 and reclaim your funds directly on L1 without waiting for any operator. Navigate to Withdraw → Emergency Exit in the dashboard. Assets are never trapped. See the Withdraw guide for details.
A Facilitator is a network participant that fronts you the ADA amount of a pending withdrawal from their own liquidity pool. They collect a small fee, and then claim the full settled amount from the state queue after the maturity window elapses. This is the accelerated withdrawal path.

Fraud Proofs and Security

An optimistic rollup executes transactions off-chain and periodically publishes a compact cryptographic summary to L1. Committed blocks are assumed valid unless someone submits a fraud proof. This gives you high throughput off-chain plus L1-grade security when disputes arise. See Midgard L2 for the architecture.
Any network participant with the ability to run a Watcher and submit L1 transactions can submit a fraud proof. If the proof succeeds, the invalid block is removed and the offending operator’s entire bond is claimed as a reward. See the Fraud Proofs page and the Watchers guide.
Your funds are not at risk during the challenge window. They remain in the L1 smart contracts at all times. Only the state claim that represents them is being verified. The maturity window exists to guarantee that verification completes before funds move.
Because the fraud-proof process is fully deterministic on the UTxO model, slashing is binary and unambiguous. There is no subjectivity or committee vote. An operator who commits an invalid block loses their entire bond when a valid fraud proof is submitted.

Bridges and Cross-Chain

Charms lets you move Bitcoin-native assets to the settlement layer without custodians. V1 uses ICP signatures; V2 verifies Groth16 zk-SNARK proofs directly on L1 using BLS12-381 pairings available as native Plutus v3 builtins. You destroy a Charm on Bitcoin and unlock a corresponding native token on the destination chain. See Charms Bridge for the full flow.
Three integration partners provide trust-minimized Bitcoin↔L1 transfers: Charms (recursive Groth16 zk-SNARK proofs), Cardinal (MuSig2 + BitVMX fraud proofs), and FluidTokens. See Architecture for how bridges fit into the stack.

Running Infrastructure

Layer Operators produce L2 blocks, commit block headers to L1, and earn transaction fees. You need reliable hardware, a bonded collateral position, and a running node pointed at both the L1 endpoint and the Sundial RPC. See the Layer Operators guide for hardware requirements and setup.
Watchers monitor the L2 for invalid blocks and submit fraud proofs when they detect one. Successful Provers earn the offending operator’s entire bond. The Watcher Toolkit ships a modular Prover reference implementation ready to deploy with minimal configuration. See the Watchers guide.
Archivists store the full bodies of confirmed L2 blocks. Only block headers are committed to L1, so Archivists preserve the complete block data. Because every confirmed state UTxO contains a chained header hash, archived data is either verifiably correct or not.

Developer Questions

Yes, with one caveat. The Sundial L2 uses the same transaction format as the settlement layer, so any library that speaks the L1 CBOR format (Lucid Evolution, Mesh, or raw CML) works for building transactions. However, you must replace the standard provider (Blockfrost, Kupmios, Maestro) with one that routes UTxO lookups to GET /utxos and submission to POST /submit on the Sundial node. See the Transactions API for details.
The API Overview lists every endpoint. Detailed pages cover Transactions, UTxOs, Blocks, and the Faucet. SDK documentation is under SDKs & Libraries.
Use the Faucet API with a bearer token. POST /faucet/claims accepts a preprod address (addr_test1...) and returns a transaction hash once the funding transaction is submitted. Rate limits and address cooldowns apply.

Still Need Help?

If your question is not covered here, check the relevant section of the documentation or reach out through the Sundial GitHub organization.