Skip to main content
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

1

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

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

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

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

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.

Withdrawing Liquidity

1

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

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

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

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.