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

# Passkey Wallet

> How Bitrune uses WebAuthn passkeys for keyless Bitcoin wallet management.

Bitrune uses **passkeys** (WebAuthn) as the sole authentication and key management mechanism. There are no seed phrases, browser extensions, or third-party wallet connections. A single biometric prompt — Face ID, Touch ID, or Windows Hello — creates a cryptographic identity and a Bitcoin deposit address in one step.

## How It Works

<Steps>
  <Step title="Create a Passkey">
    When a user clicks "Connect" for the first time, the browser triggers a WebAuthn credential creation ceremony. The user authenticates with their device biometric. The authenticator generates a credential bound to the Bitrune domain and returns a **PRF (Pseudo-Random Function)** output — a deterministic 64-byte value unique to this credential and a fixed protocol salt.
  </Step>

  <Step title="Derive a Bitcoin Key">
    The PRF output is hashed (SHA-256) to produce a valid secp256k1 private key. The corresponding 33-byte compressed public key becomes the user's on-chain identity. This derivation is fully deterministic: the same passkey on the same device always produces the same key pair.

    The private key never leaves the user's device. Bitrune's servers never see it.
  </Step>

  <Step title="Register and Generate a Deposit Address">
    The compressed public key is sent to Bitrune. The protocol combines it with the platform's public key using **MuSig2 key aggregation** and constructs a **BIP-341 Taproot address** with the following spend paths:

    * **Key-path**: 2-of-2 MuSig2 aggregate key (user + platform). Used for all normal operations — swaps, withdrawals, LP.
    * **Script-path Leaf U**: User-only spend, available after a CSV timelock (\~30 days). Allows the user to recover funds unilaterally if the platform disappears.
    * **Script-path Leaf P**: Platform-only spend, available after a longer CSV timelock (\~60 days). Allows recovery of dormant accounts.

    The resulting Taproot address (`bc1p...`) is the user's personal deposit address for BTC and Runes.
  </Step>

  <Step title="Sign Transactions">
    When a swap, withdrawal, or other operation requires the user's signature, the browser prompts for biometric verification again. The passkey re-derives the same private key via PRF, signs the requested data (MuSig2 partial signatures for cooperative spends, or plain Schnorr for recovery), and discards the key from memory after a short idle timeout.

    One biometric prompt can authorize multiple inputs in a single transaction.
  </Step>
</Steps>

## Key Properties

| Property             | Detail                                                                                                  |
| -------------------- | ------------------------------------------------------------------------------------------------------- |
| No seed phrase       | Key is derived from passkey PRF — nothing to write down or lose                                         |
| Biometric-bound      | Every signing operation requires Face ID / Touch ID / PIN                                               |
| Deterministic        | Same device + same passkey = same address, always                                                       |
| Non-custodial        | Private key never leaves the device; server only sees the public key                                    |
| Recoverable          | If the device is lost, the CSV recovery leaf allows platform-assisted fund retrieval after the timelock |
| No browser extension | Works in any modern browser with WebAuthn and PRF support                                               |

## What Happens If...

<AccordionGroup>
  <Accordion title="The user loses their device?">
    The passkey credential is gone, so the private key cannot be re-derived. However, the user's funds remain in the Taproot deposit address. After the platform recovery CSV timelock expires, Bitrune can assist with fund migration to a new address.
  </Accordion>

  <Accordion title="The user clears browser storage?">
    The credential ID stored in the browser is lost, but passkeys created as "discoverable" (resident) credentials survive on the authenticator hardware. Signing back in with the same passkey re-derives the same key and reconnects to the existing account.
  </Accordion>

  <Accordion title="The platform goes offline?">
    After the user CSV timelock expires, the user can spend their deposit UTXOs unilaterally using the script-path recovery leaf. No platform cooperation is needed.
  </Accordion>
</AccordionGroup>