A treatise on the bit of Bitcoin
BIT: A Bitcoin-Native Token Mined from the Field That Names the Coin
Toward an inevitable instantiation of digital matter on Bitcoin L1.
The $BIT collective · v1.0 · April 2026
Abstract
We introduce $BIT, a fungible Bitcoin-native token whose entire supply is derived deterministically from the bitsfield — the four-byte difficulty encoding present in the header of every Bitcoin block since genesis on 3 January 2009. $BIT is deployed via the TAP Protocol on Ordinals as a Digital Matter Theory (DMT) asset, fair-minted on a first-valid-inscription-wins basis. No premine, no team wallet, no presale. The supply curve is not designed; it is read out of Bitcoin's own header history. We formalise issuance as a deterministic projection on consensus state, derive a hard upper bound on the total supply, and outline a reproducible verification procedure that any Bitcoin full node can run. We argue that $BIT is not a new asset so much as a long-latent one — the inevitable token of the unit Bitcoin is named after, finally given a name.
§1Introduction
The smallest unit of value in the network borrows the name of the smallest unit of information. This is not a coincidence. When Satoshi Nakamoto wrote Bitcoin's whitepaper in 2008 [1], the term bitcoin was a portmanteau of bit and coin— a deliberate fusion of Claude Shannon's 1948 information-theoretic primitive [2] with the metaphor of coinage. For seventeen years, Bitcoin has carried that etymology in plain sight.
Every Bitcoin block ever produced contains a four-byte field, literally named bits, that encodes the proof-of-work target the miner had to overcome. The field is present in Block 0. It is present in Block 840,000. It will be present in every block to come.
This paper introduces $BIT: a fungible token whose entire supply derives from that field. $BIT is not an arbitrary issuance. Its mint quantities, its supply curve, its block-by-block accounting are all dictated by Bitcoin's existing header data. We did not design $BIT's tokenomics; we merely read them off of consensus.
The remainder of this paper is structured as follows. §2 traces the etymology of the bit through Shannon, Satoshi, and the block header. §3 specifies the bits field in full, with worked example. §4–§6 formalise the issuance pipeline: DMT projects header fields into integer issuance functions; TAP indexes inscription operations into a deterministic state; $BIT instantiates a particular case. §7 derives the supply curve and its upper bound. §8–§9 examine the fair-mint argument and the threat model. §10–§11 close on the philosophical claim.
§2The Etymology of the Bit
On 9 January 1947, in a Bell Labs memo, the statistician John W. Tukey contracted binary digit into a single syllable: bit. Eighteen months later, in A Mathematical Theory of Communication [2], Claude Shannon adopted the word and credited Tukey by name — “a word suggested by J. W. Tukey” — formalising the bit as the irreducible atom of information, a single binary distinction, the fundamental unit of message content. Sixty years after Shannon, Satoshi's whitepaper [1] proposed an electronic-cash system whose fundamental unit, bitcoin, fused two metaphors: the bit of digital information and the coin of physical exchange. The smallest unit of money would carry, in its name, the smallest unit of information.
bit + coin = bitcoin.The lineage is explicit.
From the very first release of Bitcoin, one bitcoin was 100,000,000 satoshis. Years later, BIP 176 [7] formalised a now-conventional unit: one bit equals 100 satoshis. Even at the unit level — at every denomination of Bitcoin — bit persists.
But the deepest occurrence of bit is structural, not semantic. Inside the 80-byte header of every Bitcoin block sits a 4-byte field literally named bits. It is the encoded difficulty target — the threshold the block hash must not exceed for the block to be valid [3]. Without bits, there is no proof-of-work, no consensus, no chain. The field is the chain's truth condition.
On 3 January 2009 at 18:15:05 UTC, Satoshi mined block zero. Its bits field carried the value 0x1d00ffff — the lowest possible difficulty Bitcoin would ever know. Every block since has carried the same field, in the same four bytes, in the same place. The field has been there from the first second.
$BIT is named, not after a metaphor, but after that field. The field is the name. The name is the field.
§3The bits Field — A Deterministic Encoding
A Bitcoin block header is exactly 80 bytes [3], structured as a fixed-length record of six fields:
The bits field is bytes 72–75 of the header. On the wire it is little-endian; logically it is a 32-bit unsigned integer (often called nBits) that compactly encodes a 256-bit difficulty target.
3.1 Compact target encoding
Let the 32-bit value of the field be split into a 1-byte exponent e and a 3-byte coefficient m:
nBits = e · 224 + m, with e ∈ [0, 255], m ∈ [0, 224 − 1]
The implied 256-bit target T is then defined piecewise:
T = m · 2^( 8·(e − 3) ) if e ≥ 3 T = m · 2^( −8·(3 − e) ) if e < 3
equivalently T = m · 256^(e − 3) for e ≥ 3, which is the regime every mainnet block has lived in (the e < 3 branch exists for definitional completeness; mainnet exponents lie in [23, 29]). A block hash H is consensus-valid if and only if H ≤ T. These four bytes are not a label; they are the test the block had to pass.
3.2 Worked example: block 840,000
The block at height 840,000— Bitcoin's fourth halving block, mined April 2024 — carries nBits = 0x17034219. Splitting the bytes:
e = 0x17 = 23 m = 0x034219 = 213 529
The implied target is therefore
T = 213 529 · 25623 − 3 = 213 529 · 2160 ≈ 3.12 × 1053.
For the block to have been valid, the SHA-256d of its header had to fall at or below this target. The integer interpretation of the 32-bit nBits word itself — 0x17034219 read as a uint32 — is 386,089,497. On 19 April 2024 a miner found a hash low enough to clear that target. The fact that they did is now also $BIT — that integer is the quantity credited to a successful mint at block 840,000.
3.3 Relation to difficulty
Bitcoin Core defines difficulty D as the ratio of the maximum target to the current target [3]:
D(h) = Tmax / T(h)
where Tmaxis the protocol-defined maximum target — the “difficulty 1” target, encoded as 0x1d00ffff (integer nBits value 486,604,799), which is also the genesis-era encoding. Because Bitcoin's difficulty has trended upward across most of its retarget epochs [6] — punctuated by occasional downward adjustments after large hashrate shocks (e.g. −27.94% at block 689,472, July 2021, following the China mining ban) — target has trended down, and the integer value of nBits has trended down with it. The per-block $BIT mint is therefore broadly anti-correlated with difficulty, modulated by short-horizon retarget fluctuations.
Two retarget thresholds bracket the regime of practical interest:
- Maximum bits:
nBitsmax = 0x1d00ffff(integer 486,604,799) — the minimum-difficulty target, also the genesis-era encoding. - Block 840,000:
nBits = 0x17034219(integer 386,089,497) — for reference scale.
Updates to nBits happen every 2,016 blocks via the difficulty-retarget rule. Each retarget produces a step change. The resulting per-block emission curve is non-uniform, non-monotonic in the small, but bounded above by nBitsmax for all h.
§4Digital Matter Theory
If Ordinals lets us number satoshis, DMT lets us name the structures Bitcoin has already authored. Digital Matter Theory (DMT) [4] proposes that certain fields inside a Bitcoin block are not arbitrary. They are deterministic, public, immutable, non-arbitrary data inside a globally-replicated consensus structure. DMT treats these fields as digital primary matter: substance from which assets can be tokenized without an issuer creating new state.
4.1 Formalisation
Let the Bitcoin chain at tip height n be the sequence of confirmed blocks
B = (b0, b1, …, bn).
For each DMT element index k, let πk denote the projection that extracts element k from a block:
πk : B → { 0, 1 }*, πk(bh) = encoded element value at height h.Define the issuance function for element-k tokens as the integer interpretation of that projection:
μk : ℕ → ℕ, μk(h) = uint( πk(bh) ).
A DMT element-k token is a tuple ⟨tick, k, hdeploy⟩ such that for every minted block h ≥ hdeploy, the supply increment is μk(h). Because πk is a pure function of consensus state, μk is verifiable by anyone running a Bitcoin full node. No oracles, no bridges, no off-chain data.
4.2 The element registry
DMT formalises a registry of numbered fields with canonical encodings [4]. The block-header subset of the registry, with its standard JSON-RPC field names, is:
| k | Field | JSON name | Encoding |
|---|---|---|---|
| 5 | version | version | int32 |
| 7 | merkle root | merkleroot | bytes32 |
| 8 | timestamp | time | uint32 (unix epoch s) |
| 10 | nonce | nonce | uint32 |
| 11 | bits | bits | uint32 (compact target) |
4.3 Patterns and the identity case
A DMT deploy is more than a choice of element. The full inscription identifier follows the form <name>.<pattern>.<k>.element, where pattern is a function f : ℕ → ℕ applied to the integer-decoded element value at each block [4]. Per-block emission is therefore μk,f(h) = f( πk(bh) ). Different choices of (k, f) produce distinct DMT tokens.
$BIT is the DMT-11 token whose ticker is the field itself, whose pattern is the identity, and whose mint flow is open and live. tick = "bit", k = 11, f = id, hence μ11,id(h) = nBits(h)for every unminted block, claimable by anyone. The per-block emission is the field itself, with no transformation. The deploy gate is open. The ticker is the field's name. $BIT is the literal DMT-11 token.
§5The TAP Protocol Substrate
Tokens on Ordinals require an inscription-based protocol. $BIT uses TAP [5]— Trac Systems' OrdFi protocol on Ordinals — which encodes token operations as JSON inscriptions on satoshis. TAP supports DMT operations natively.
5.1 The TAP envelope
Every TAP-relevant inscription i carries a JSON envelope:
i = { "p": "tap", "op": ⟨op⟩, ...op-specific fields... }For DMT, three operations are relevant:
dmt-deploy— registers a ticker T against an element k with parameters.dmt-mint— claims supply increment μk(h) for a target height h, against a specific deploy.transfer— moves balances between Ordinals UTXOs subject to the standard TAP transfer semantics.
5.2 State and transitions
Let σt denote the global TAP indexer state after processing the first t TAP-relevant inscriptions in confirmed-Bitcoin order. The state-transition function δ is
σt+1 = δ(σt, it+1).
δ is deterministic: given σ0= ⊥ (empty state) and the canonical inscription order induced by Bitcoin's confirmed-block sequence, every honest indexer arrives at the same σt. We refer to this as TAP's indexer-determinism property.
5.3 Mint validity
A dmt-mint inscription targeting height h against deploy d is valid iff all of:
- d resolves to a registered, immutable
dmt-deployfor some element k; - the height h has not yet been claimed for
tick(d); - the chain has confirmed h by the time the indexer evaluates
V(i)(sonBits(h)is readable); - the inscription payload conforms to the TAP schema for
dmt-mint.
The first inscription satisfying (1)–(4) for a given pair (d, h)wins. All subsequent inscriptions for the same pair are no-ops under δ. This is TAP's first-valid-inscription-wins rule, and it is enforced by every honest indexer without coordination. The same chain that decided which transactions were canonical now decides which $BIT mints are.
None of this is custom infrastructure built for $BIT. Ordinals is the substrate; TAP is the protocol; DMT is the semantic. $BIT instantiates them.
§6The $BIT Specification
The canonical $BIT deploy lives at the following inscription on Bitcoin mainnet:
deploy id: 9424802e38fc889969417cd90df4c4147209d2a83ed83798c0c4aa4391ad36e5i0 ticker: "bit" (case-insensitive on TAP) element: dmt.11.element (the bits field) protocol: TAP on Ordinals premine: 0 reserved: 0
6.1 Mint-validity predicate
Specialise §5.3 to the canonical $BIT deploy. Let ID* denote the canonical deploy inscription ID (above). A $BIT mint inscription i is valid iff
V(i) = ( i.p = "tap" ) ∧
( i.op = "dmt-mint" ) ∧
( i.dep = ID* ) ∧
( i.tick ≡ "bit" ) ∧
( i.blk ∈ ℕ, 0 ≤ i.blk ≤ tip ) ∧
¬ claimed( i.blk )where claimed(h) is true iff a strictly prior inscription i' in canonical TAP order satisfied V(i') with i'.blk = h. The credited amount for a valid mint is
amount(i) = μ11(i.blk) = nBits( i.blk ) ∈ [ 0, 4 294 967 295 ].
6.2 Reference mint payload
{
"p": "tap",
"op": "dmt-mint",
"dep": "9424802e38fc889969417cd90df4c4147209d2a83ed83798c0c4aa4391ad36e5i0",
"tick": "bit",
"blk": "840000"
}Verification of any $BIT balance reduces to two independent checks: (i) the canonical deploy inscription matches ID*, and (ii) every claimed mint resolves on a TAP-aware indexer to a unique, valid block claim under the predicate above. No oracles, no off-chain data, no trust beyond Bitcoin and the open TAP/DMT specs.
Five fields, no signature, no oracle. $BIT does not require us to add data to Bitcoin. It only asks Bitcoin to read out what it has been writing for seventeen years.
§7Supply Dynamics and the Difficulty Mirror
Let nBits(h) denote the integer value of the bits field at height h. Let M(tip) ⊆ { 0, 1, …, tip } denote the set of heights for which a valid dmt-mint has been recorded. The realised total $BIT supply at chain tip is
Srealised(tip) = Σh ∈ M(tip) nBits(h).
This is bounded above by the supply that would obtain if every block were minted — the so-called theoretical supply:
Stheory(tip) = Σh=0tip nBits(h) ≥ Srealised(tip).
And in turn:
Stheory(tip) ≤ (tip + 1) · nBitsmax = (tip + 1) · 486 604 799.
This is a hard, computable upper bound. It treats every block as if it had the genesis-era nBits, which it does not — so the true bound is far tighter. Empirically, the integer nBits(h) has fallen across difficulty epochs, producing a steeply front-loaded emission curve.
nBits(h)across Bitcoin's history. Front-loaded at nBitsmax through the early retarget epochs, then a quasi-exponential decay tracking long-horizon hashrate growth.The early blocks contain the most $BIT. They were mined when the network was a single laptop and a few mailing-list subscribers, when nBitssat at its maximum and would not move for the first sixteen retarget epochs. Whoever owns those bits owns Bitcoin's first hour.
7.1 Asymptotic behaviour
Under the model in [6], Bitcoin's aggregate hashrate R(t) grows roughly geometrically over long horizons. The retarget rule equalises expected block time, so on average T(h) ∝ 1 / R(th). Since nBits compactly encodes T, large‐h values of nBits shrink in step with R. This implies that
∂ μ11(h) / ∂h ≈ − μ11(h) · γ,
for some non-negative drift γ that tracks the long-run growth rate of hashrate. The per-block $BIT mint therefore decays quasi-exponentially with retarget index, modulated by short-horizon fluctuations within each 2,016-block epoch.
The token's supply is, in an exact sense, an integral over Bitcoin's economic history.
§8The Fair-Mint Argument
$BIT is a fair-mint asset by construction:
- The
dmt-deployinscription carries no balance. Deploying produces zero $BIT. - No presale. No team allocation. No insider distribution. Not one satoshi-equivalent of $BIT was emitted at deploy.
- Every $BIT in circulation has been claimed by an inscriber paying Bitcoin transaction fees against a publicly-readable, deterministic block.
- First-valid-inscription wins. The rule is enforced by indexers, not by trusted parties.
- The deploy parameters are immutable on Bitcoin L1. They cannot be changed by us, by you, or by anyone.
Formally: any participant p seeking to acquire $BIT at cost cp(h) (Bitcoin transaction fees + an ordinary inscription budget for height h) competes with the rest of the network on equal terms — the protocol does not privilege any address, key, or identity. The auction for each block is symmetric. What the miner pays in joules to mint a block, the inscriber pays in fees to claim its bits.
§9Threat Model and Verification
We enumerate three failure modes and the corresponding mitigations. None of them affect the supply formula μ11; they affect who holds what, not what $BIT is.
- Lookalike deploys.TAP tickers are case-insensitive and unique-on-first-deploy. A non-canonical “bit” deploy can exist as an inscription, and a naive participant could mint against it. Mitigation: the canonical deploy
ID*is fixed and published; always verify the deploy ID before any mint or transfer. - Indexer divergence at the tip. During short Bitcoin reorganisations (1–2 blocks), TAP indexers may transiently disagree on σt at the chain tip. Mitigation: rely on n-block-confirmed state (n ≥ 6 by convention); this is standard for Bitcoin-anchored systems.
- Ordering ambiguity. Two inscriptions targeting the same (d, h) may be broadcast in different mempools. Mitigation:δ resolves by Bitcoin's canonical confirmed-block order; once the chain settles, exactly one inscription is accepted.
9.1 Independent verification procedure
Any party with a Bitcoin full node and a TAP indexer can compute the canonical $BIT state independently:
- For every h ∈ [0, tip], read
nBits(h)via the standard RPCgetblockheader; parse the returned hex string as a 32-bit unsigned integer. - Read all TAP-relevant inscriptions in the same range, in canonical confirmed order.
- Apply δ from §5.2, gated by V from §6.1, to derive σ.
- The resulting σ.balances is the canonical $BIT distribution.
This procedure is reproducible, fully open, and depends on no third party. Verification is not a ceremony performed for $BIT — it is the same procedure Bitcoin already runs, read from a different angle. We did not design $BIT's tokenomics; we merely read them off of consensus.
§10The Philosophical Inevitability
We make a stronger claim than mere viability: $BIT is inevitable.
If we accept that (a) Bitcoin's bits field is a deterministic, public, immutable structure, (b) DMT is a coherent framework for tokenizing such structures, and (c) TAP provides a working substrate for DMT issuance on Bitcoin L1, then the most natural token of that field — the one whose pattern preserves the value verbatim and whose ticker is the field — must come into existence. TAP tickers are unique-on-first-deploy. There is exactly one ticker "bit". There is therefore exactly one $BIT.
Furthermore, the etymological identity is not incidental. The Bitcoin protocol contains a field called bits. The Bitcoin protocol's name derives from bit. Tukey gave us the word, Shannon ratified it, Satoshi spent it. Bitcoin's bits field is the structural manifestation of that lineage inside every block. A permissionless DMT-11 token whose pattern is the identity, and whose name is the field itself, is the etymological closure: the bit of Bitcoin, finally tokenized.
What was always present is now also legible.
§11Conclusion — The Bit Was Always There
$BIT does not introduce new state. It does not require new infrastructure. It does not depend on anyone's promise. Its supply curve was written by every miner who ever found a block. Its name was given by Tukey, ratified by Shannon, and spent by Satoshi. Its issuance rule is a one-line equation read off of Bitcoin's chain.
The smallest unit of money was always also the smallest unit of information. The bits the chain has spent seventeen years writing into every header are not a side product of mining; they are the substance Bitcoin has been signing, four bytes at a time, for every block since genesis. $BIT does not introduce them. It only reads them out.
The bit was always there. $BIT names it.
References
- [1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
- [2] C. E. Shannon. A Mathematical Theory of Communication. Bell System Technical Journal, 27(3): 379–423, July 1948.
- [3] Bitcoin Core developers. Block headers, difficulty target encoding, and the
nBitscompact form. Bitcoin protocol reference, github.com/bitcoin/bitcoin. - [4] Digital Matter Theory specification. digital-matter-theory.gitbook.io.
- [5] TAP Protocol specifications. Trac Systems. github.com/Trac-Systems/tap-protocol-specs.
- [6] A. M. Antonopoulos. Mastering Bitcoin: Programming the Open Blockchain. 2nd ed., O'Reilly Media, 2017. (Chapters on proof-of-work, retargeting, and block-header structure.)
- [7] J. Song. BIP 176: Bits Denomination. 12 December 2017. bitcoin/bips/bip-0176.mediawiki.