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

# Frequently Asked Questions

> Answers to common questions about Sundial Protocol, including staking, withdrawals, fraud proofs, wallet support, and testnet participation.

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

<AccordionGroup>
  <Accordion title="What is Sundial Protocol?">
    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.
  </Accordion>

  <Accordion title="What can I do on Sundial today?">
    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](/testnet-guide) for a walkthrough.
  </Accordion>

  <Accordion title="Is Sundial live on mainnet?">
    Sundial is currently in testnet on Preprod. Mainnet timing follows successful testnet milestones. Do not send real BTC or ADA to any testnet address.
  </Accordion>

  <Accordion title="Which wallets are supported?">
    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](/guides/connect-wallet) page.
  </Accordion>
</AccordionGroup>

## Staking and Yield

<AccordionGroup>
  <Accordion title="What is the difference between staking BTC and staking ADA?">
    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.
  </Accordion>

  <Accordion title="What are FIRE and ICE tokens?">
    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.
  </Accordion>

  <Accordion title="How are rewards paid?">
    Rewards accrue in the asset you staked (BTC or ADA) and are visible in the Portfolio tab of the dashboard. See [Tokenomics](/concepts/tokenomics) for how fees and rewards flow through the system.
  </Accordion>
</AccordionGroup>

## Withdrawals and Exits

<AccordionGroup>
  <Accordion title="How long do withdrawals take?">
    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.
  </Accordion>

  <Accordion title="What if no operator is producing blocks?">
    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](/guides/withdraw) for details.
  </Accordion>

  <Accordion title="What is a Facilitator?">
    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.
  </Accordion>
</AccordionGroup>

## Fraud Proofs and Security

<AccordionGroup>
  <Accordion title="What is an optimistic rollup?">
    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](/concepts/l2-rollup) for the architecture.
  </Accordion>

  <Accordion title="Who can submit a fraud proof?">
    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](/components/fraud-proofs) page and the [Watchers guide](/guides/watchers).
  </Accordion>

  <Accordion title="How safe are my funds during the challenge window?">
    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.
  </Accordion>

  <Accordion title="How does slashing work for operators?">
    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.
  </Accordion>
</AccordionGroup>

## Bridges and Cross-Chain

<AccordionGroup>
  <Accordion title="How does the Charms bridge work?">
    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](/components/charms-bridge) for the full flow.
  </Accordion>

  <Accordion title="Which bridges does Sundial integrate?">
    Three integration partners provide trust-minimized Bitcoin↔L1 transfers: **Charms** (recursive Groth16 zk-SNARK proofs), **Cardinal** (MuSig2 + BitVMX fraud proofs), and **FluidTokens**. See [Architecture](/concepts/architecture) for how bridges fit into the stack.
  </Accordion>
</AccordionGroup>

## Running Infrastructure

<AccordionGroup>
  <Accordion title="How do I become a Layer Operator?">
    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](/guides/operators) for hardware requirements and setup.
  </Accordion>

  <Accordion title="What does a Watcher do?">
    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](/guides/watchers).
  </Accordion>

  <Accordion title="What is an Archivist?">
    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.
  </Accordion>
</AccordionGroup>

## Developer Questions

<AccordionGroup>
  <Accordion title="Can I use standard L1 libraries with the Sundial API?">
    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](/api/transactions) for details.
  </Accordion>

  <Accordion title="Where do I find the API reference?">
    The [API Overview](/api/overview) lists every endpoint. Detailed pages cover [Transactions](/api/transactions), [UTxOs](/api/utxos), [Blocks](/api/blocks), and the [Faucet](/api/faucet). SDK documentation is under [SDKs & Libraries](/sdk/midgard-sdk).
  </Accordion>

  <Accordion title="How do I claim testnet ADA programmatically?">
    Use the [Faucet API](/api/faucet) 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.
  </Accordion>
</AccordionGroup>

## 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](https://github.com/sundial-protocol).