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

# Deflationary Runes

> Per-swap tax mechanics for deflationary Runes configured at etch time.

Bitrune supports **deflationary Runes** with per-swap tax mechanics configured at etch time. Tax rules are immutable after broadcast.

## Overview

A deflationary Rune applies a tax on swaps. The tax is deducted from the output amount and distributed across one or more configurable buckets.

## Tax Parameters

| Parameter      | Range   | Description                               |
| -------------- | ------- | ----------------------------------------- |
| `buy_tax_bps`  | 0–10000 | Tax on BTC-to-Rune swaps, in basis points |
| `sell_tax_bps` | 0–10000 | Tax on Rune-to-BTC swaps, in basis points |

* Tax is applied **after** the pool fee and **before** the user receives the output.
* A value of 0 disables the tax for that direction.

## Tax Distribution Buckets

Each deflationary Rune defines one or more **distribution buckets**. Bucket allocations must sum to exactly 10000 bps (100%).

| Bucket       | Behavior                                                                           |
| ------------ | ---------------------------------------------------------------------------------- |
| **BURN**     | Runes are permanently removed from circulation via a Runestone `OP_RETURN` output. |
| **AUTO\_LP** | Runes are injected into the pool as single-sided liquidity.                        |
| **ADDRESS**  | Runes are sent to a configured wallet address. Maximum 3 address buckets per etch. |

## Immutability

Tax rules are **immutable after broadcast**. Neither the etcher nor the platform can modify tax parameters or bucket allocations after the etching transaction confirms.

## Verification

A deterministic hash of the tax configuration is computed for client-side verification:

```
params_hash = SHA256(canonical_json(rules))
```

The hash is computed from a deterministic JSON serialization (sorted keys, no whitespace) and is verifiable by any third party given the rule set.

### On-Chain Audit Tags

Tax rules can be independently verified on-chain using **Tag 111** and **Tag 777** audit tags embedded in the etching transaction. These tags anchor the tax configuration to the Bitcoin blockchain, allowing anyone to confirm that the published rules match the on-chain commitment. See the [On-Chain Audit Tags](/protocol/on-chain-audit) documentation for the full verification mechanism.

## Example Configuration

```
buy_tax_bps:  500   (5%)
sell_tax_bps: 1000  (10%)

buckets:
  - type: BURN
    share_bps: 5000    # 50% of tax burned
  - type: AUTO_LP
    share_bps: 3000    # 30% of tax re-liquified
  - type: ADDRESS
    address: bc1q...creator
    share_bps: 2000    # 20% of tax to creator wallet
```

### Worked Example (sell side)

1. User sells 10,000 Runes into the pool.
2. Pool fee (30 bps) is applied first; AMM computes a gross BTC output.
3. Sell tax of 1000 bps (10%) is applied to the Rune input: `tax = 10000 × 1000 / 10000 = 1000 Runes`.
4. Tax distribution:
   * **BURN**: `1000 × 5000 / 10000 = 500 Runes` permanently destroyed.
   * **AUTO\_LP**: `1000 × 3000 / 10000 = 300 Runes` added to pool reserves.
   * **ADDRESS**: `1000 × 2000 / 10000 = 200 Runes` sent to creator wallet.
5. User receives BTC output computed from the remaining 9,000 Runes.