BIT Protocol

Bitcoin runs on incentives. The miners that secure the chain are paid two ways: a per-block subsidy set by the halving schedule, and the transaction fees inside each block. The subsidy halves every roughly four years, asymptotically toward zero — the last fractional satoshi disappears near 2140. Today the subsidy is 3.125 BTC per block; after the 2028 halving, 1.5625; after 2036, ≈ 0.39; after 2044, ≈ 0.1. With each halving, Bitcoin's security depends more on the fee market — and the fee market has been volatile, episodically near-zero, and never load-tested as the sole carrier of Bitcoin's security. [3]

This is the security-budget problem, and it is the central quantitative concern raised about Bitcoin's long-run sustainability — by Bitcoin's own builders, by independent researchers, and across every academic treatment of the network's long-run incentive compatibility. [1] [4] What has not yet emerged is a credible, deployable, on-chain mechanism for adding new, durable, miner-bound revenue streams to Bitcoin — additive to the subsidy and the fee market, not replacing either.

BIT Protocol is that mechanism. It generalizes per-block-token-emission redirection — the technique by which a token can pay its emissions to the coinbase outputs of the block its mint event was anchored to — into a small, opt-in, constrained on-chain grammar. Any token deployer can use it for their own ticker. There is no review queue, no per-tick patch, and no gatekeeper. The validator enforces the same rules for every project; every change waits a 144-block notice floor before it activates.

Today, exactly one token does this, by hardcode. BIT Protocol opens the same path to every token, by the same rules — and as more token deploys opt in, the security-budget surface compounds. This is the most credible additive contribution to Bitcoin's long-run security budget available today.

This paper has three goals: specify the grammar in enough detail that an independent implementation could match the reference; argue the security-budget thesis; and be honest about what the protocol does not solve and where its failure modes live.

Bitcoin's per-block reward consists of two components: the subsidy S(h) set by the halving schedule, and the sum of transaction fees F(h) paid by the transactions included in the block. The total per-block reward to the block producer is R(h) = S(h) + F(h), where h is the block height.

S(h) is deterministic and falls geometrically: roughly 50 BTC for the first 210,000 blocks, halving every 210,000 blocks thereafter. F(h)is empirical — it depends on demand for blockspace, on the marginal user's willingness to pay, and on the technological landscape of L2 and sidechain alternatives that compete for that demand.

2.1 Subsidy decay

The subsidy halves every 210,000 blocks (≈ four years) and decays geometrically. After the 2028 halving the subsidy is 50 / 2⁵ = 1.5625 BTC per block; after 2036, ≈ 0.39 BTC; after 2044, ≈ 0.098 BTC. The function approaches zero but never reaches it within human-relevant time:S(h) → 0 only as h → ∞; the last fractional satoshi falls out of the schedule around block height ≈ 6,930,000, near calendar year 2140. The security-budget concern is not the year zero is reached. It is that, decades earlier, the subsidy ceases to dominate miner revenue, and the network must rely on a fee market that has never been load-tested at that scale.

2.2 Fee-market fragility

Empirically, fees have at times been a meaningful fraction of block reward — during congestion peaks driven by Ordinals, Runes, and BRC-20 inscription waves; during macro-driven mempool stress; during fee spikes triggered by exchanges consolidating UTXOs. [5]Empirically, fees have also been near zero for extended quiet stretches, including weeks where the marginal next-block fee fell below the typical relay's default minimum.

A security budget that asymptotes to a fee market alone is a security budget whose floor is the volatility of demand for inclusion. A 51%-attacker's rational calculus depends on the steady-state attainable revenue from honest mining; if that steady-state floor is too thin, attack economics shift. [6]

2.3 What the network needs

What the network needs, then, is a mechanism that adds structural, deploy-funded, on-chain revenue streams to the miner-bound side of the equation — additive to R(h), not in tension with the subsidy or the fee market. Tokens that mint per-Bitcoin-block via DMT-style issuance (where each block-anchored mint event reads on-chain data and produces a token allocation) are an obvious candidate for such a mechanism: the issuance is already on-chain, already deterministic, and already happens once per block. What is missing is the general-purpose plumbing to route each mint's economic surface to the block winner — and to do so without a single project getting hardcoded into the protocol source.

Per-Bitcoin-block-anchored token issuance is not a new technique. Tokens deployed against a Bitcoin block field — the difficulty target, the nonce, a hash window — produce a determined integer allocation per block. The first valid inscription claiming a given block's allocation wins it; subsequent claims for the same block are rejected.

What is new is the routing. By default, the allocation is owned by the inscriber — the wallet that broadcast the claim, whoever they are. Pay-to-the-inscriber is the path of least resistance, and is the path most existing deploys take.

3.1 The redirect alternative

The redirect alternative pays the allocation to the miner of the block instead — pro-rata across the coinbase outputs of the very block whose data was used to produce the mint. The inscriber still does the cryptoeconomic work of pinning the mint to Bitcoin (paying the inscription fee, choosing the block, etc.), but the resulting tokens flow to the people securing that block. Where redirect has been done before, it has been done via per-token hardcoded paths — a constant in protocol source naming a single ticker, gated by an activation height. [7]

3.2 The state of the art: one ticker, by hardcode

At the time of writing, $NAT is the only DMT token whose per-block emissions flow to miners. The mechanism is a single-ticker, single-path hardcode that activates at block height 885,588 and routes emissions to coinbase outputs from that height onward. The chain has been honoring it ever since.

The mechanism works as designed. The problem is not the mechanism — the problem is that it exists for one ticker. Every other DMT token's emissions still flow to the inscriber by default. There is no shared path, and no protocol-level way to opt one in without a per-tick patch on someone else's review queue.

3.3 BIT Protocol generalizes the path

BIT Protocol takes the same primitive and removes the per-tick hardcoding. The deployer of any eligible token writes a small redirect rule as a single inscription. The rule names recipients, weights them in basis points summing to 10,000, and declares an activation height at least 144 blocks in the future. The validator does the routing, on-chain, deterministically, for any token whose deployer has signed an eligible rule. Same rules, every project, no exceptions.

3.4 Backward compatibility — data, not code

The protocol's indexer is a superset. It runs the new redirect grammar for tokens that opt in, and it indexes the existing DMT-class assets already deployed on Bitcoin L1. $NAT's on-chain history continues to read the same as it always has — including its original miner-reward inscription:

{
  "p": "tap",
  "op": "reward",
  "type": "miner",
  "block": "885588"
}

Backward compatibility is implemented as data, not code. The reference indexer ships with a small manifest enumerating redirect rules that predate BIT Protocol — currently a single entry for $NAT — which the same generic engine processes alongside opt-in inscriptions. The indexer source carries no per-tick branches; entries are added, removed, or audited by editing the manifest, not the code. The manifest is part of each release tag and verifiable against the public hash. Adding other legacy redirects in the future is a config change, not a code change.

The result: $NAT holders see no migration, no re-issuance, and no required action. Balances and transfers stay valid. The redirect path that pays $NAT emissions to coinbase outputs continues without interruption. Markets that integrate one BIT Protocol indexer get balances, transfers, and trading data for $BIT, $NAT, and every DMT token the index covers.

The grammar is constrained on purpose. Smaller surfaces have smaller bug surfaces; smaller bug surfaces are easier to audit and easier to reason about under reorgs.

4.1 The redirect op

The complete payload shape:

{
  "p": "bit",
  "op": "redirect",
  "tick": "<tick>",
  "act": <block_height>,
  "rule": {
    "type": "weighted-split",
    "must_sum_to": 10000,
    "buckets": [/* up to 8 */],
    "solo_classification": { /* optional */ }
  }
}

4.2 Bucket types

Each bucket directs a fraction of per-block emissions to one of three recipient types. Up to eight buckets per rule; bucket weights expressed in basis points and summing to exactly 10,000.

Shieldedrecipients route emissions to the block's coinbase outputs; the recipient set is therefore determined by the block producer at the time the block is mined, not at the time the rule is inscribed. Address recipients are deployer-named at inscription time and remain fixed for the lifetime of the rule.

4.3 Weighted splits

A bucket has the shape:

{
  "name": "solo-jackpot",
  "share_bps": 5000,
  "recipient": {
    "type": "solo-coinbase-output",
    "accumulate_when_no_solo": true
  }
}

Validator constraints, in order of evaluation: bucket count ≤ 8; each share_bps an integer in [1, 10000]; sum of all share_bps exactly 10000; recipient type one of the three specified above; address recipients carry a syntactically valid BTC mainnet address (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR).

4.4 The rationale for eight

Eight buckets is enough to express realistic distributions — general-pool plus solo-jackpot plus a small treasury plus several tributes is six; eight gives slack. More than eight is rarely a real composition; it is more often a sign the rule should have been split into a hierarchy, which the v1 grammar does not support. v2 may; v1 deliberately does not.

4.5 Phased element coverage

The grammar is intentionally scoped to the DMT element types the protocol currently knows how to anchor a deterministic per-block allocation against. The MVP launch covers element 11 deploys without a pattern constraint — the shape both $NAT and $BIT use. Element 11 is the four-byte difficulty-target field of the Bitcoin block header; deploys without a pattern produce one allocation per block from the deploy height onward, with no further filtering.

Pattern-based element-11 deploys (UNAT-style and similar) and other DMT elements — element 4 (block height), element 10 (nonce), and any element formally added to the DMT spec — are queued behind the MVP. Each addition ships behind its own validator-extension review. Phase priority is decided by community vote, weighted by demand.

When a rule contains a solo-coinbase-output bucket, the validator must classify each block as either solo or non-solo. Classification is deployer-configurable per rule. The grammar supports two signals — coinbase-tag substring matching and coinbase-address matching — with a tie-breaker policy for ambiguous blocks.

{
  "solo_classification": {
    "tags_substring": [
      "/solo.ckpool.org/",
      "Public Pool on Umbrel",
      "/braiinssolo/",
      "/Mined @ SoloPool.Com/",
      "NiceHash"
    ],
    "addresses": [],
    "ambiguous_block_policy": "treat_as_pool"
  }
}

The classifier is deployer-named because the solo-mining landscape evolves: pools come and go, address rotations happen, new identifiers emerge. Hardcoding the classifier in protocol source would re-introduce exactly the gatekeeper problem the redirect mechanism exists to solve.

5.1 Why solo blocks matter

Hashrate decentralization is one of Bitcoin's durably-underrated security properties. The fewer pools that control a majority of the network's hashrate, the easier it becomes to coordinate censorship, withhold blocks, or stage attacks; the more independent solo miners exist, the harder the coordination becomes. [8] A protocol-level mechanism that pays solo blocks structurally — not just sometimes, not just by lucky incidence — is the only on-chain tool we know of for biasing the long-run distribution of hashrate toward solo miners.

6.1 Authorization model

Authorization for a redirect rule is by the original deployer of the tick. Concretely, the inscription carrying the redirect rule must declare the deploy inscription as its Ordinals parent(envelope tag 3) and the reveal transaction must actually transfer the parent inscription's sat. [9]A declared parent that is not actually transferred is filtered out by the protocol's sat-tracking layer; whoever currently holds the deploy inscription's UTXO is therefore the authority. Authority transfers with the deploy inscription's sat.

This model has two properties worth naming. First, control tracks Bitcoin's native ownership semantics — the deployer holds the inscription, the deployer controls the rule. Second, control is transferable: a deployer can sell or hand over authority by transferring the deploy inscription. There is no separate registry and no off-chain key management.

6.2 Activation

Every rule must declare an activation height act with act > current_block + 144 (strict). About one day of advance notice. Holders of the token always see the new rule one day before it changes routing. This is a hard floor; the validator rejects any rule that does not clear it.

6.3 Updates and cancellation

Updates are a re-inscription: a fresh redirect rule with the same parent and a new act at least 144 blocks in the future. The old rule continues to apply until the new act. The new rule queues regardless of whether the old rule is in force or only scheduled — the queue is keyed on tick and activation height, so a rule scheduled but not yet active can still be replaced (with the same notice floor).

There is no revoke or sunset op in v1. To wind a rule down, the deployer inscribes a fresh rule with the new desired distribution — possibly back to pay-the-inscriber, expressed as a singleaddress bucket pointing at a designated wallet — and the 144-block notice floor applies.

Three components compose the reference implementation.

7.1 Indexer

The indexer reads Bitcoin blocks linearly from a configured start height, scanning for inscriptions that carry one of the protocol ops (deploy, mint, redirect, etc.). For each, it runs the validator. Valid ops mutate the indexer's state; invalid ops are dropped with a recorded rejection reason for forensic inspection.

7.2 Validator

The validator is a pure function from (state, op, block_context) ↦ (state', decision). Determinism is the operative invariant: any two indexers that replay the same Bitcoin chain from the same start height must arrive at the same state. The validator never reads off-chain data, never depends on wall-clock time, and never branches on non-Bitcoin-deterministic inputs.

7.3 Per-block dispatcher

For each Bitcoin block, the dispatcher: resolves the active redirect rule for every token with a mint event in the block; classifies the block according to each rule's solo policy; computes per-bucket allocations; and emits a per-block ledger entry naming bucket, recipient resolution (e.g. which coinbase output, which address), and amount. The ledger is replayable from genesis.

7.4 Reorgs

On a Bitcoin chain reorg, the indexer rolls back state to the common ancestor and re-applies the new chain. Because the validator is deterministic, the post-reorg state matches what an indexer that had only ever seen the new chain would produce. No special-case logic for redirect rules is required: a rule inscribed in a now-orphaned block is simply not part of the canonical chain and therefore does not exist in the post-reorg state.

$BIT is the native token of BIT Protocol. As the protocol grows — more tokens deploying, more redirect rules in flight, more activity flowing through the indexer — the gravity around $BIT compounds. Protocol surface area and $BIT's economic surface are tied together by design.

8.1 Why $BIT is coupled to ecosystem growth

The economic logic is structural. Every token that opts into BIT Protocol's redirect grammar uses the protocol's indexer, validator, and per-block dispatcher. Each new deploy adds traffic, adds usage, and adds value capture surface for $BIT. The protocol's usage curve is $BIT's value curve. The two move together.

8.2 Token economics — community-decided

The detailed economics — fee surface, value-capture mechanics, allocation between any combination of buyback, holder distribution, and protocol treasury — are decided with the community before launch. The protocol publishes candidate structures, hosts an on-chain ballot, and inscribes the winning rule as the activation rule for the economic surface. Final shape, weights, and mechanics ship in a follow-up version of this paper before launch on Bitcoin L1.

8.3 Fair-mint history

$BIT is fair-mint. Every $BIT in existence was minted from a Bitcoin block by the public, anchored to the difficulty target of that block. There is zero presale, zero team allocation, and zero protocol-reserved pool. The token already lives on Bitcoin L1; the protocol is being built around it.

9.1 Replay determinism

Replay determinism is the protocol's strongest correctness claim. The reference indexer ships with a test suite that replays a published canonical chain segment and asserts the resulting state matches a published expected hash. Independent implementations are expected to match. Divergence is a bug.

9.2 Censorship resistance

Inscribing a redirect rule has the same censorship surface as any other Bitcoin transaction. Block producers may decline to include a rule inscription, but cannot prevent it from being included by the next willing block producer. There is no protocol-level moderator and no protocol-level allow-list. A sufficiently censoring miner cabal could delay any specific rule inscription by some bounded number of blocks, after which the inscription lands.

9.3 Authorization theft

Because authorization is by deployer-UTXO control, authorization theft reduces to inscription-UTXO theft. This is exactly as hard as stealing any other Bitcoin UTXO of equivalent economic weight: the deployer's wallet hygiene is the protocol's authorization hygiene. The protocol does not introduce a new attack surface here.

9.4 Solo-classifier manipulation

A rule with a solo-coinbase-outputbucket and an accumulator can be manipulated by a sophisticated pool operator who alters their coinbase scriptSig to match the classifier's solo signal — capturing the accumulator while running pool-shape operations under the hood. The defense is in the deployer's hands: the classifier list is deployer-named, can include addresses as well as substrings, and can be updated (with the standard 144-block notice). Solo classification is not, and is not claimed to be, fully manipulation-proof.

9.5 Audit

Before go-live, the protocol commissions an independent third-party security audit. The firm and the report are published when both are ready. The audit's scope covers the indexer, validator, per-block dispatcher, and the redirect grammar. It does not cover individual deployers' rules: those are user content, validated at submission time but not audited for economic soundness.

Three phases. Code first, then launch on Bitcoin L1, then open the protocol to other builders. Delivery is not gated on outside parties.

10.1 Phase 1 — MVP, live on Bitcoin L1

• Indexer, validator, and per-block dispatcher reach a stable release.
• Element 11 no-pattern deploys supported — covers $NAT, $BIT, and any new deploy in this shape.
• Test suite covering grammar boundary conditions, classifier edge cases, and reorg behavior.
• Independent third-party audit clears with no open critical findings.
• $BIT holds an on-chain ballot on the shape of its first redirect rule (general-pool, solo-jackpot, hybrid). Winning rule is inscribed with the 144-block notice.
• First-party DEX ships in parallel.

10.2 Phase 2 — Expansion

• Pattern-based element-11 deploys (UNAT-style and similar).
• Element 4 (block height) and element 10 (nonce) added by community vote.
• v2 grammar with richer recipient types.
• Bridges and liquidity infrastructure broaden $BIT's economic reach beyond Bitcoin-only venues.
• Pace driven by demand; each addition ships behind its own validator-extension review.

10.3 Phase 3 — Ecosystem

• SDKs and hosted indexer endpoints.
• Deploy-and-rule-management tooling for new projects.
• Mining-pool BD partnerships to broaden solo-classifier coverage.
• Every new token that opts in compounds the security-budget surface and the $BIT-denominated ecosystem.

The argument of this paper is short. Bitcoin's long-run security budget is a real concern; the fee market alone is not a reliable floor; on-chain, deploy-funded, miner-bound revenue streams are the most credible additive contribution available; the only thing standing between that contribution and reality is a small grammar — small enough to audit, small enough to reason about, small enough to ship — applied to every token by the same rules.

BIT Protocol is that grammar.

The grammar is specified in §4. The classifier is specified in §5. The authorization model is specified in §6. The architecture is specified in §7. $BIT's role in the economic surface is specified in §8. The threat model and verification plan is specified in §9. Phase 1 is in flight, audit is queued, and go-live on Bitcoin L1 happens when both clear.

1. [1]Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. (2008)
2. [2]Bitcoin Core. The halving schedule, GetBlockSubsidy(). (ongoing)
3. [3]Carlsten, M., Kalodner, H., Weinberg, S. M., Narayanan, A. On the Instability of Bitcoin Without the Block Reward. (2016)
4. [4]Lavi, T., Rottenstreich, O., Mizrahi, A., Ross, K. The Future of Bitcoin's Security: A Survey of Long-Run Sustainability Concerns. (2024)
5. [5]mempool.space. Historical fee data and block-reward composition. (ongoing)
6. [6]Eyal, I., Sirer, E. G. Majority Is Not Enough: Bitcoin Mining Is Vulnerable. (2014)
7. [7]Public Bitcoin block explorers. Coinbase-output redirection mechanisms in extant DMT-style deploys. (ongoing)
8. [8]Bitcoin developer mailing list and academic literature on hashrate centralization risks. (ongoing)
9. [9]Casey, R. Ordinals envelope specification — parent inscription tags. (2023)