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

# Security

> Authentication, integrity, and operational security measures in the Bitrune protocol.

## Schnorr Signature Authentication

Every authenticated request is signed with a **BIP-340 Schnorr signature** tied to the user's Bitcoin public key.

* The user signs a message containing the HTTP method, request path, timestamp, and body hash.
* The protocol verifies the signature against the user's registered public key.
* No passwords, cookies, or session tokens are used for user authentication — identity is proven cryptographically on every request.

### Timestamp Binding

Each signed request includes a Unix timestamp. Requests where the timestamp diverges from the current time by more than a narrow window are rejected, preventing replay attacks using captured signatures.

### Body Integrity

The SHA-256 hash of the request body is included in the signed message. Any modification to the body after signing invalidates the signature, ensuring end-to-end integrity of every request.

## Rate Limiting

A per-IP token-bucket rate limiter protects the protocol from abuse. Each IP address is allocated a sustained request rate with burst capacity. Requests exceeding the limit are temporarily rejected until the bucket refills.

## MuSig2 Custody Guarantees

User deposit addresses are secured by **2-of-2 MuSig2** key aggregation between the user and the platform. Neither party can unilaterally move deposited funds. See the [Custody Model](/protocol/custody) for full details on the address structure and spend paths.

## CSV Recovery Timelocks

Dual **CheckSequenceVerify (CSV)** timelocks provide independent recovery paths:

| Recovery Path     | Approximate Timelock | Purpose                                             |
| ----------------- | -------------------- | --------------------------------------------------- |
| User recovery     | \~30 days            | User reclaims funds if the platform goes offline    |
| Platform recovery | \~60 days            | Platform recovers dormant funds after a longer wait |

The user timelock is always shorter than the platform timelock, ensuring the user has priority in any recovery scenario.

## Session Expiry and Balance Release

MuSig2 signing sessions have a limited lifetime. When a session expires without completing:

* All balances locked for that session are automatically released back to the user's available balance.
* The expired session cannot be resumed; the user must initiate a new signing flow.

This prevents funds from becoming permanently locked due to abandoned or interrupted operations.

## Reorg Detection

The protocol maintains a rolling window of recent block hashes. On each new block, the parent hash is compared against this window. A mismatch signals a chain reorganization, triggering re-evaluation of affected deposits:

* Deposits that were credited but are no longer confirmed on the new chain tip are rolled back.
* The deposit state machine re-processes affected transactions against the reorganized chain.

This ensures the protocol's view of user balances remains consistent with the canonical Bitcoin chain.