> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bitrune.org/llms.txt
> Use this file to discover all available pages before exploring further.

# How It Works

> The user journey through Bitrune at a high level.

## 1. Registration

The user creates a **passkey** (WebAuthn) with a biometric prompt — Face ID, Touch ID, or Windows Hello. The browser's authenticator returns a PRF (Pseudo-Random Function) output, which is hashed to derive a secp256k1 key pair deterministically. The private key never leaves the device; only the compressed public key is sent to Bitrune.

The platform combines the user's public key with its own via **MuSig2** (BIP-327) to derive an aggregate public key. This becomes the Taproot internal key for a **P2TR deposit address** (BIP-341). The address also commits to two CSV recovery script-path leaves for unilateral recovery. The result is a unique deposit address per user — no seed phrase, no browser extension, just a biometric.

Each user is also assigned a unique **6-character invite code** (e.g. `A3K9F2`) for the referral system.

## 2. Deposit

The user sends BTC (or Runes) to their deposit address. The platform monitors the mempool and blockchain for incoming transactions. Deposits progress through three states: **mempool** (detected but unconfirmed), **confirming** (included in a block), and **credited** (meets the confirmation threshold, currently 1 confirmation). Optimistic credit is applied at the mempool stage for a faster UX.

## 3. Swap

Bitrune supports BTC-to-Rune and Rune-to-BTC swaps through **constant-product AMM pools** (`x × y = k`). Two execution paths exist: **virtual swaps** for pre-etch Runes (balances updated internally only) and **on-chain MuSig2 swaps** for post-etch Runes (a signed Bitcoin transaction moves real UTXOs). A 0.3% fee is deducted from each swap and accrues to liquidity providers.

## 4. Liquidity Provision

Users deposit BTC and a Rune at the current pool ratio to become **liquidity providers**. In return they receive **LP shares** proportional to their contribution. Minting and burning of shares follows a constant-product model. LP providers earn their pro-rata share of swap fees. A separate protocol fee (`kLast` accrual) may apply.

## 5. Mining

Users can **stake LP-Rune tokens** into mining pools to earn **BITRUNE** rewards. Rewards are distributed per-block based on the proportion of staked shares. Users can unstake at any time and claim accumulated rewards via MuSig2 cooperative signing.

## 6. Referral Rebate

Every user has a unique **invite code**. When a referred user trades, the referrer earns **BITRUNE** rewards proportional to the trade volume. Users can bind a referrer via invite link (`?ref=CODE`) at registration, or manually enter an invite code afterward. Referral binding is one-time and immutable.

## 7. Rune Etching

Users can create (etch) a new Rune directly from the Bitrune interface. Etching parameters include name, symbol, divisibility, supply cap, and optional **deflationary tax rules** (e.g., a percentage of each transfer is burned). The etching transaction is constructed and broadcast on Bitcoin mainnet.

## 8. Withdrawal

To withdraw, the user initiates a request and the platform co-signs a **MuSig2 cooperative spend** that sends funds to the user's specified external address. This is the normal-path Taproot key-path spend — a single aggregated Schnorr signature that is indistinguishable from an ordinary P2TR spend on-chain.

## 9. Recovery

If the platform becomes unreachable, the user can **self-recover** funds without any cooperation. The deposit address includes Taproot script-path leaves with a **CSV timelock** (default: 30 days / \~4320 blocks). After the timelock expires, the user can broadcast a script-path spend using only their own key. No third party or guardian is required.