diff --git a/bip-????.mediawiki b/bip-????.mediawiki
new file mode 100644
index 0000000000..e99982ba60
--- /dev/null
+++ b/bip-????.mediawiki
@@ -0,0 +1,97 @@
+<pre>
+  BIP: ?
+  Layer: Consensus (soft fork)
+  Title: Consensus ScriptPubKey Length Limit In Most Blocks
+  Author: billymcbip@proton.me
+  Status: Draft
+  Type: Specification
+  License: MIT
+  Discussion: 2025-10-02: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/cgnE52cSAgAJ
+  Version: 1.0.0
+</pre>
+
+==Abstract==
+
+Limit the size of new ScriptPubKeys at the consensus level (including OP_RETURN outputs) in most (255/256) blocks.
+
+==Specification==
+
+Transactions in blocks at or above the activation height (''tbd'') cannot include outputs with ScriptPubKeys that are longer than 260 bytes unless the block height is a factor of 256 (<code>block_height % 256 == 0</code>).
+
+==Motivation==
+
+Bitcoin is money. Transactions embedding arbitrary data compete with financial transactions for block space, and many node operators clearly do not want to process, relay or store arbitrary data.
+
+The motivation of this BIP is to reduce the amount of arbitrary data that can be embedded in transactions and in the UTXO set.
+
+A system with N independent bits of freedom can carry at most N bits of information. Limiting the length of ScriptPubKeys reduces independent bits of freedom within a block. More non-arbitrary bytes would have to wrap arbitrary bytes embedded in ScriptPubKeys.
+
+Since Bitcoin is money, we must avoid setting any precedent for confiscation, i.e. making previously spendable UTXOs unspendable. Some users may hold pre-signed transactions that create new ScriptPubKeys longer than 260 bytes and no longer control the private keys that signed them. To avoid invalidating these transactions, we allow them to be processed in one out of every 256 blocks (<code>block_height % 256 == 0</code>), i.e. in roughly one block every ~42 hours. BIP34 lets us extract the block height from the coinbase transaction. Of course, this exception also allows any other large OP_RETURN outputs to be included in those blocks, but such transactions are throttled.
+
+==Rationale==
+
+'''Why limit OP_RETURN at all? Why not block OP_RETURN completely?'''
+
+It is impossible to completely prevent arbitrary data in blocks. Therefore, it makes sense to continue offering a less harmful way to embed data, i.e. OP_RETURN.
+
+However, OP_RETURN should only be ''marginally'' more attractive for data embedding than methods leading to arbitrary data in the UTXO set.
+
+'''Why 260 bytes?'''
+
+The length of ScriptPubKeys for all standard outputs is well below 260 bytes:
+* P2PK: up to 67 bytes
+* P2MS: up to 201 bytes (max. 3 keys are standard)
+* P2PKH: 25 bytes
+* P2SH: 23 bytes
+* P2WPKH: 22 bytes
+* P2WSH: 34 bytes
+* P2TR: 34 bytes
+* WITNESS_UNKNOWN: up to 42 bytes
+
+A 260 byte limit allows 256 bytes of data in OP_RETURN outputs:
+<pre>
+  1  byte  OP_RETURN
+  1  byte  OP_PUSHDATA2
+  2 bytes  length
+256 bytes  data
+</pre>
+
+Any limit is somewhat arbitrary, but 256 is a multiple of 32, i.e. 8 SHA-256 hashes could be embedded.
+
+'''Why not limit non-OP_RETURN outputs to 34 bytes?'''
+
+Firstly, simplicity: A simple length check is easier to implement, no need to discriminate between OP_RETURN outputs and other outputs.
+
+Secondly, unknown unknowns: We may need longer scriptPubKeys in the future.
+
+'''Why change consensus rather than mempool policy?'''
+
+If we accept large OP_RETURN outputs in consensus but not in mempool policy, more transactions will be submitted directly to mining pools. This creates centralization pressure (see https://bitcoincore.org/en/2025/06/06/relay-statement/).
+
+'''Why does this BIP not include other measures to limit data embedding?'''
+
+The idea of this BIP is to allows the community to discuss the merits of a ScriptPubKey size limit in isolation. Limiting ScriptPubKey size can be an atomic change, it does not have to be implemented in conjunction with other, more complex anti-spam measures that constrain ''which'' UTXOs can be spent (rather than ''how'' UTXOs can be spent).
+
+==Backwards Compatibility==
+
+Soft fork, backwards compatible.
+
+==Reference Implementation==
+
+''tbd''
+
+==Deployment==
+
+''tbd''
+
+==Credits==
+
+This BIP is inspired by parts of the "Reduced Data Temporary Softfork" (https://github.com/bitcoin/bips/pull/2017).
+
+@moonsettler and @portlandhodl provided direct feedback.
+
+@portlandhodl suggested a 520-byte limit without a block height exception. See: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/cgnE52cSAgAJ
+
+==Copyright==
+
+This document is licensed under the MIT License.