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

# On-Chain Audit Tags

> Verifiable AMM state proofs embedded in every Bitrune transaction via Runestone odd-tags.

Bitrune embeds AMM state proofs directly into Bitcoin Runestone transactions, making it the first automated market maker where every swap, liquidity event, and tax execution is independently verifiable from the blockchain alone. No trust in Bitrune's servers is required.

## How It Works

The Runes protocol encodes Runestone messages in OP\_RETURN outputs. Even-numbered tags are reserved for standard protocol fields (etchings, edicts, and so on), while odd-numbered tags are available as protocol extensions. Bitrune claims a set of odd-tag slots and writes structured audit data into every on-chain transaction it produces.

Each tag carries a versioned payload of `u128` values. Any Bitcoin node that can decode a Runestone can extract the odd-tag values and independently replay the AMM's state transitions — confirming that reserves, fees, share calculations, and tax distributions match the constant-product formulas.

## Tag Registry

| Tag ID | Name                 | Embedded In               | Purpose                                                                                                                   |
| ------ | -------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| 111    | Tax Specification    | Deflationary Rune etch tx | Records the immutable tax rules — buy/sell tax rates, bucket distribution percentages, and a `params_hash` — at etch time |
| 333    | Swap Data            | Every swap tx             | Records `rune_id`, direction (buy or sell), `amount_in`, `amount_out`, and `fee_in`                                       |
| 555    | Reserve Proof        | Every swap tx             | Records pre/post pool reserves, `fee_bps`, total LP shares, and accumulated fee-per-share                                 |
| 777    | Tax Execution Proof  | Deflationary swap tx      | Records gross amount, tax amount, net amount, per-bucket distribution, and `params_hash`                                  |
| 889    | Pool Parameters      | Pool creation etch tx     | Records `fee_bps`, initial reserves, and protocol fee accrual flag                                                        |
| 999    | LP Event Proof       | LP deposit/withdraw tx    | Records operation type, token amounts, shares delta, pre/post reserves, and LP rewards                                    |
| 1111   | Batch Settlement     | Multi-user batch tx       | Records user count, total Rune input, total BTC output, and pre/post reserves                                             |
| 1333   | LP-Rune Linkage      | LP-Rune etch tx           | Binds the LP share token to its parent pool's `rune_id`, `fee_bps`, and initial supply                                    |
| 1555   | Mining Stake/Unstake | Mining stake tx           | Records staking or unstaking of LP-Rune tokens into mining pools                                                          |
| 1777   | Mining Claim         | Mining claim tx           | Records BITRUNE reward claim amounts and block height                                                                     |
| 1999   | Rune Withdraw        | Rune withdrawal tx        | Records Rune withdrawal details                                                                                           |

## Verification Model

An independent verifier needs nothing beyond a Bitcoin full node (or any Runestone-aware indexer) and basic arithmetic.

### 1. Swap Verification

Fetch any swap transaction and decode its Runestone. Extract Tag 333 (swap data) and Tag 555 (reserve proof). Verify:

* The output amount follows the constant-product formula: `amount_out = (amount_in_net × reserve_out) / (reserve_in + amount_in_net)`, where `amount_in_net = amount_in - fee_in`.
* Post-swap reserves equal pre-swap reserves adjusted by the input and output amounts.
* The constant-product invariant holds: `post_reserve_a × post_reserve_b >= pre_reserve_a × pre_reserve_b`.

### 2. Tax Verification

For deflationary Runes, additionally extract Tag 777 (tax execution proof) from the swap transaction. Verify:

* `net_rune = gross_rune - tax_total`.
* Each bucket's share of the tax matches the immutable distribution rules. Cross-reference Tag 111 from the Rune's original etch transaction to obtain those rules.
* The `params_hash` in Tag 777 matches the `params_hash` in Tag 111. A mismatch proves the rules were tampered with between etch and execution.

### 3. LP Verification

Extract Tag 999 from any deposit or withdrawal transaction. Verify:

* The share calculation matches the constant-product formula (proportional to contributed liquidity for deposits; pro-rata for withdrawals).
* Reserve changes are consistent with the deposited or withdrawn amounts.
* The fee-per-share accumulator is monotonically increasing across successive transactions, confirming that fees are never lost or retroactively altered.

### 4. Rule Immutability

Tag 111 is written exactly once, at etch time. It contains a `params_hash` — the SHA-256 digest of the canonical JSON representation of the tax rules. Every subsequent deflationary swap embeds this same hash in its Tag 777 payload. If the two hashes diverge, any observer has cryptographic proof that the rules were changed after the original commitment.

## On-Chain Anchor

For deflationary Runes, an additional OP\_RETURN output carries a compact binary anchor:

```
"BITRUNE" (7 bytes) || 0x01 (version) || params_hash (32 bytes)
```

This 40-byte payload allows any party to verify the tax rules directly from the raw transaction, without needing to decode the full Runestone tag structure. It serves as a secondary, protocol-independent commitment to the same rules recorded in Tag 111.

## Why This Matters

* **No trust required.** Any node operator can replay the AMM math from on-chain data alone. Bitrune's servers are a convenience layer, not a trust boundary.
* **Immutable rules.** Deflationary tax configuration is locked at etch time and cryptographically pinned by `params_hash`. There is no admin key, governance vote, or upgrade path that can alter them after the fact.
* **Complete audit trail.** Every swap, LP event, and batch settlement leaves a verifiable on-chain footprint. Nothing happens off-chain that isn't provable on-chain.
* **Cross-reference integrity.** Tag 777's `params_hash` must match Tag 111's, creating an unbroken chain from each swap execution back to the original rule commitment. A single mismatch is sufficient to prove protocol violation.