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 ofu128 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), whereamount_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_hashin Tag 777 matches theparams_hashin 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 aparams_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: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_hashmust 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.