# Bitcoin OP_RETURN Usage After Bitcoin Core v30

> Bitcoin OP_RETURN usage by day: outputs, bytes of data, share of block weight and payloads over the old 80-byte limit, before and after Bitcoin Core v30.

Markdown copy of https://voltfincrypto.com/apps/bitcoin-op-return-usage

**Question:** How much Bitcoin block space do OP_RETURN outputs use since Bitcoin Core v30?

- Kind: Dashboard in Voltfin Vantage
- Topic: [Bitcoin](https://voltfincrypto.com/topics/bitcoin)
- Chains: Bitcoin
- Status: Planned. The data is not published yet, so this page states no figure; each figure will open its receipt when it is.

An OP_RETURN output lets a Bitcoin transaction carry data in an output that can never be spent, so it never enters the UTXO set. For years Bitcoin Core relayed only one such output per transaction, with at most 80 bytes of data. Bitcoin Core v30, released in October 2025, raised that default to roughly the size of a whole standard transaction and allowed several OP_RETURN outputs, which split node operators and drew attention to Bitcoin Knots.

This dashboard measures what blocks actually contain. Node policy only decides what a node relays; any valid OP_RETURN can be mined, and larger ones sometimes were long before v30. Counting outputs, bytes and their share of block weight every day shows whether the new default changed what miners include, and which uses, from runestones to larger data payloads, account for the space.

## Blueprint

### Now

OP_RETURN outputs in the latest day of blocks.

- **OP_RETURN outputs, latest day** (count): OP_RETURN outputs in blocks mined during the latest complete UTC day.
- **OP_RETURN data, latest day** (bytes): Payload bytes in every OP_RETURN output mined during the latest complete day.
- **Share of block weight** (%): OP_RETURN output weight as a share of the weight of all blocks mined that day.
- **Payloads over 80 bytes, latest day** (count): Transactions whose OP_RETURN data adds up to more than the old 80-byte default.
- **Outputs by payload class** (count): Daily OP_RETURN outputs split into runestones, known protocol markers and unknown data.
- **Largest payloads this week**: The biggest OP_RETURN payloads mined in the last seven days, with size, fee rate, block and the pool that mined it.

### Since v30

How OP_RETURN usage changed across the release and its adoption.

- **Oversized payloads, 30 days** (count): Transactions with OP_RETURN data over 80 bytes, or more than one OP_RETURN output, in the last 30 days.
- **Pools mining oversized payloads** (count): Mining pools whose blocks included an OP_RETURN payload over 80 bytes in the last 30 days.
- **OP_RETURN bytes by day** (bytes): Payload bytes mined per day over the selected period, with the v30 release date marked.
- **Share of block weight by day** (%): OP_RETURN weight as a share of all block weight each day, with payloads over 80 bytes drawn as their own line.

Filters: Period (Last 30, 90 or 365 days).

## How it will be measured

- Every output whose script starts with OP_RETURN is read from each block, with its payload length in bytes after the opcode and the data pushes.
- Share of block weight counts each OP_RETURN output at four weight units per byte, since output data gets no witness discount, against the block's total weight.
- Payloads are classed by prefix: runestones (OP_RETURN followed by OP_13), known protocol markers and unknown data; the class rules are published with the page.
- Transactions whose OP_RETURN data adds up to more than the old 80-byte default, or that carry more than one OP_RETURN output, are counted apart from the rest.

## Data it needs

- `bitcoin_network_daily` (to build): Blocks, hashrate implied by difficulty, difficulty, fees, transaction counts, block weight and miner revenue (subsidy plus fees) per day.
- `bitcoin_inscriptions_daily` (to build): Inscriptions, rune etchings and mints, BRC-20 transfers, and the fees they paid per day.
- `address_labels` (to build): Labels for known addresses: exchanges, bridges, protocols, funds, treasuries, sanctioned addresses and known attackers.
- Source: Every Bitcoin output whose script begins with OP_RETURN, with its payload length, per block
- Source: Block weight and transaction weight from each block
- Source: Coinbase tags of each block, for the pool that mined large OP_RETURN payloads
- Source: Fees paid by transactions carrying OP_RETURN outputs, from inputs minus outputs

## Questions

### What is OP_RETURN in Bitcoin?

An opcode that marks an output as provably unspendable, used to attach a small piece of data to a transaction. Because such outputs can never be spent, nodes do not keep them in the UTXO set.

### What changed in Bitcoin Core v30?

The default data carrier limit, which had allowed one OP_RETURN output with up to 80 bytes of data, was raised to about the size of a standard transaction, and transactions may now carry several such outputs. Operators can still set a lower limit in their own node's settings.

### Did the OP_RETURN limit ever apply to blocks?

No. The 80-byte limit was a relay and mining policy default, not a consensus rule, so a block that included a larger OP_RETURN was always valid. Policy shapes what most nodes pass along; it does not decide what a miner may include.

### Is OP_RETURN data cheaper than inscriptions?

No. Data in outputs counts at full weight, while inscriptions sit in the witness, which is discounted four to one. Per byte, OP_RETURN data uses more block weight, which is one reason most large data has gone into the witness.

### Why does the OP_RETURN debate matter?

Supporters of the change argued that data will be embedded anyway and does less harm in outputs that stay out of the UTXO set. Opponents argued that a higher default invites non-monetary use of block space. This page measures usage; it does not take a side.

## Glossary

- **Data carrier**: Bitcoin Core's name for OP_RETURN outputs that carry data, and for the setting that limits their size.
- **Weight unit**: Bitcoin's measure of block space. Witness bytes count as one unit and all other bytes as four.
- **Standardness**: The relay and mining policy a node applies on top of the consensus rules.

## Related apps

- [Bitcoin Node Count: Bitcoin Core vs Knots Share](https://voltfincrypto.com/apps/bitcoin-node-count-core-vs-knots)
- [Bitcoin Ordinals, Runes and BRC-20 Activity](https://voltfincrypto.com/apps/bitcoin-ordinals-runes-activity)
- [Bitcoin Runes List: Top Runes by Holders and Mints](https://voltfincrypto.com/apps/bitcoin-runes-list)
- [Bitcoin UTXO Set Size: Unspent Outputs and Dust](https://voltfincrypto.com/apps/bitcoin-utxo-set-size)
- [Bitcoin Transaction Fees and Mempool Tracker](https://voltfincrypto.com/apps/bitcoin-fees-mempool-tracker)
- [Bitcoin Halving Countdown and Block Reward](https://voltfincrypto.com/apps/bitcoin-halving-countdown)

Build it in Voltfin Studio: https://app.voltfincrypto.com/signup?next=%2F