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

# Providing Liquidity

> How to deposit and withdraw liquidity from Bitrune AMM pools.

Liquidity providers deposit paired BTC and Rune amounts into a pool and receive LP shares in return. Fees from every swap accrue implicitly by increasing the reserve-to-share ratio over time.

## Depositing Liquidity

<Steps>
  <Step title="Check the current pool ratio">
    Each pool has a BTC reserve, a Rune reserve, and total shares outstanding. The deposit must match the current ratio to avoid donating excess tokens.
  </Step>

  <Step title="Calculate paired amounts">
    Given one side's amount, derive the other:

    ```
    amount_rune = amount_btc * reserve_rune / reserve_btc
    ```

    Alternatively, the protocol auto-pairs when only one amount is supplied.
  </Step>

  <Step title="Preview the deposit">
    Provide the pool, BTC amount (in satoshis), and Rune amount (in base units). The preview shows the number of shares that will be minted and the effective ratio applied.
  </Step>

  <Step title="Execute the deposit">
    * **Ledger-only pool:** The platform updates internal balances; no on-chain signature is needed.
    * **On-chain pool (MuSig2):** Sign the presented BIP-340 sighashes with your private key (Schnorr partial signatures), then submit your public nonces and partial signatures. The platform aggregates and broadcasts.
  </Step>

  <Step title="Receive LP shares">
    LP shares are credited proportional to the contribution. They are tracked separately and do not appear as a fungible token in the user's Rune balance.
  </Step>
</Steps>

## Withdrawing Liquidity

<Steps>
  <Step title="Preview the withdrawal">
    Specify the pool and the number of LP shares to burn. The preview shows the BTC and Rune amounts to be returned, which include the proportional share of accumulated fees.
  </Step>

  <Step title="Execute the withdrawal">
    * **Ledger-only pool:** Submit the withdrawal request directly.
    * **On-chain pool (MuSig2):** Sign the presented sighashes, then submit your nonces and partial signatures.
  </Step>

  <Step title="Receive assets">
    The user receives BTC and Rune amounts proportional to the shares burned. Because fees have been accruing since deposit, the withdrawal typically returns more than the original deposit (minus any impermanent loss).
  </Step>
</Steps>

## Key Concepts

### First Liquidity Provider

The first LP to deposit into a new pool sets the initial price ratio. There is no oracle; the ratio is determined entirely by the amounts deposited.

### Share Calculation

For subsequent deposits, shares are calculated as:

```
shares = min(amount_btc * total_shares / reserve_btc,
             amount_rune * total_shares / reserve_rune)
```

The lesser side determines the number of shares minted. Any excess on the other side is a small donation to the pool (it is not returned).

### Impermanent Loss

Bitrune pools follow the constant-product model. When the external price of the Rune changes relative to BTC, the pool rebalances through arbitrage. The resulting divergence loss compared to simply holding both assets is called impermanent loss.

### Fee Accrual

Swap fees (default 0.3%) are added to the reserves on every trade. No separate claiming step exists; the fee share is realized when the LP withdraws.

### Protocol Fee

When enabled, approximately 16.67% of fee growth is directed to the protocol treasury. This follows the `kLast` accrual mechanism. The remaining fee growth benefits LPs.

### Balance Invariant

The system maintains the invariant:

```
confirmed_balance + LP_committed == sum_credited
```

LP shares are tracked separately from the general balance ledger.