Organic Bitcoin (OBTC) Whitepaper V1 (Implementation-Aligned, Extended Readable Edition)

Version: 1.0
Status: Request for Comments (RFC)
Audience: protocol engineers, wallet developers, mining pools, exchanges, researchers, operations teams, and community builders

0. Reading guide

The goal of this whitepaper is to make the system clear, not to bury the reader in jargon or present a speculative manifesto detached from implementation.

To lower the reading barrier, the suggested order is:

• 3-minute version: Section 1, Section 2, Section 5.1
• Product and operations version: Section 6 (lifecycle), Section 11 (wallet), Section 14 (operations)
• Engineering version: Section 7 (index), Section 8 (REAP), Section 9 (replay protection), Section 13 (security)
• Economics and governance version: Section 12 (economics), Section 15 (governance)

This document uses English technical terms directly, such as UTXO, Replay Protection, Mempool, and Coinbase.
Each of them is also explained in plain language in Section 19 (Glossary).

1. OBTC in one sentence

OBTC is a chain evolved from a Bitcoin fork:

• coins still exist as UTXOs;
• but every UTXO has a lifecycle;
• after expiry it can be reclaimed by a system-level mechanism called REAP (Reclaim Expired Assets Protocol):
  • 70% is returned to the original script as a refund,
  • 30% enters the miner security budget as tax;
• and Namespace Isolation + Replay Protection are used together to reduce cross-chain replay risk and accidental cross-chain transfers.

From a user point of view, the rule is:

Your asset is not "permanently static and automatically safe." It is an asset that requires periodic maintenance while remaining continuously protected by system rules.

1.1 Why it is called Organic

"Organic Bitcoin" does not mean "organic food Bitcoin."
It means a Bitcoin system with metabolism.

In comparison:

• Bitcoin behaves more like an inorganic system: once a UTXO is created it can remain still forever; state accumulates; and long-term miner security remains tied to the halving clock.
• OBTC behaves more like an organic system: assets go through creation, use, dormancy, expiry, reclaim, and regeneration; state can clean itself through REAP; and miner income gains an endogenous source from dormant supply returning to circulation.

The point is not that Bitcoin is "bad" because it is static. Bitcoin chose immutability of ownership expectations as a foundational social and technical norm, and that choice produced extraordinary monetary clarity. OBTC is asking a narrower question: what happens if we take the long-run maintenance burden of state and dormancy seriously enough to encode a lifecycle around it?

So "organic" is not a branding word. It points to lifecycle, recycling, and the system's ability to sustain itself.

1.2 Where the innovation sits

Many of the underlying primitives in OBTC are not brand-new inventions, for example:

• UTXO expiry windows
• deterministic candidate selection and transaction construction
• OP_RETURN markers and commitments
• state summaries and index maintenance

The innovation is not mainly "new cryptography."
It is the combination of known mechanisms into an executable economic system that directly answers a question long ignored:

If permanent on-chain state is not free, who keeps paying for it over time?

2. Why build this at all

The motivation for OBTC is not that inactivity is morally wrong, nor that every long-term holder should be forced into constant motion. The motivation is that a Bitcoin-like system has long-run structural questions that are easy to ignore in prosperous periods and difficult to answer later under stress.

2.1 The real-world problem

The traditional UTXO model has a long-term structural issue:

• part of the supply will become permanently dormant because of lost keys, inaccessible estates, broken backups, or operational failures;
• those assets remain nominally on-chain while no longer participating in economic circulation;
• and the network security budget becomes increasingly uncertain as subsidy declines and fees become more important.

Each of those points matters on its own. Together, they create a sharper problem. A chain may preserve nominal ownership records forever even when a meaningful fraction of those claims have become economically dead. Meanwhile, the system still asks active users, node operators, and miners to carry the consequences of that historical accumulation.

2.2 OBTC's answer

OBTC does not assume that permanent dormancy is the best default state.
Instead, it introduces an "organic metabolism" model:

1. the expiry mechanism brings long-unmoved assets into a governable state;
2. system reclaim routes part of dormant supply back into the security budget;
3. the refund mechanism avoids pure confiscation;
4. wallet-side renewal tools help active holders keep assets alive at much lower cost.

What is important here is the closure of the loop. Expiry alone would only create a punishment mechanism. Reclaim without refund would look like outright seizure. Refund without renewal tooling would create a brittle user experience. Wallet renewal without protocol consequences would leave the underlying security-budget problem unresolved. OBTC attempts to make each component justify the others.

2.3 Design targets

• sustained security budget,
• clear asset lifecycle,
• deterministic behavior,
• operationally manageable systems,
• script neutrality after expiry.

2.4 Non-goals

• an asset model that lets users ignore maintenance forever,
• permanent storage of all historical transaction bodies by every node,
• complex treasury governance or discretionary distribution logic.

3. System overview: a three-layer architecture

OBTC can be understood as three layers with different responsibilities.

This separation is not just an explanatory convenience. It is how the system avoids conceptual confusion. One of the easiest ways to misunderstand OBTC is to mix up three different questions:

1. what the chain must accept or reject,
2. how miners and nodes should construct or prioritize valid behavior,
3. how users and automation systems should observe risk and act before protocol penalties matter.

OBTC draws those boundaries explicitly so that consensus remains strict, mining policy remains practical, and wallet/product logic remains flexible.

3.1 Consensus Layer

This layer answers: what is a valid transaction and a valid block.

Core responsibilities:

• expiry determination,
• REAP validity rules,
• replay-protection enforcement after activation.

Consensus is where ambiguity has to die. Different node implementations must converge here even when operators disagree, hardware differs, or blocks arrive under adversarial conditions. That is why expiry is expressed as a height-based rule rather than as a vague "long enough" concept, and why REAP validity is tied to marker checks, ordering constraints, and accounting invariants.

Consensus is also where the system draws hard boundaries around what users may no longer do. An expired UTXO is not merely "risky." After the relevant activation, it is no longer spendable through the ordinary path. Likewise, replay protection is not merely an ergonomic recommendation after activation; it becomes a direct validity requirement.

3.2 Mining and Policy Layer

This layer answers: within the valid set, how should blocks be assembled safely.

Core responsibilities:

• REAP candidate selection and construction,
• reserving weight budget for REAP in block templates,
• separating system transactions from ordinary mempool policy.

This layer matters because valid behavior is still not the same thing as safe or stable behavior. A miner needs a deterministic way to discover expired candidates, construct REAP transactions, respect block-size constraints, and keep system transactions separate from ordinary user transaction flow.

Policy is also where anti-MEV and anti-abuse concerns become practical. Canonical ordering, input ceilings, reserved block weight, and mempool exclusion all reduce the surface area for strategic manipulation without having to invent a broad new governance layer. In other words, the mining/policy layer exists to make the reclaim path executable under real block-building constraints.

3.3 Wallet Execution Layer

This layer answers: how users discover risk and take action.

Core capabilities:

• obtc.getexpiry: inspect expiry risk,
• obtc.renew: renew manually,
• renewall: renew in batches,
• Auto-Renew: automated renewal with failure backoff and budget ceilings.

This layer is where OBTC becomes usable rather than merely enforceable. A lifecycle rule without lifecycle tooling would shift too much burden onto memory, manual calendars, or after-the-fact crisis response. The wallet layer turns the protocol rule into actionable information: what is safe, what is expiring, what is already expired, and what the next low-risk action should be.

The wallet layer is also where controlled automation becomes realistic. Capability-based authorization, staged execution, scheduler limits, and audit trails do not belong in consensus. They belong in the execution environment that helps active users, operators, and wallet software stay ahead of expiry.

4. The core mechanism in plain language

Start with the most intuitive example.

Assume you hold a 1 BTC UTXO:

1. it is created at height h_create;
2. it becomes expired at height h_create + E, where E is the expiry window;
3. if you renew before that point, the asset remains under your active control;
4. if you never do anything, the system may execute REAP inside a block:
   • return 0.7 BTC to the original script,
   • count 0.3 BTC as miner tax,
   • start a new timer for the refund output.

This example is deliberately simple, but it already shows the core structure. OBTC does not destroy value at the expiry height. It changes the legal state of the UTXO inside the protocol. Before expiry, only the owner can spend it through the ordinary path. After expiry, the ordinary path closes and the system reclaim path becomes available.

Two practical clarifications matter:

First, expiry does not mean instantaneous confiscation at one exact block. It means the UTXO enters a class that miners are permitted to process through REAP subject to ordering, limits, and block-template policy. The exact block in which reclaim happens depends on block construction and available capacity.

Second, renewal is intentionally much cheaper than being reaped. The intended user experience is not repeated loss. It is periodic maintenance. For an attentive holder, the dominant action is usually to renew or move the asset long before the reclaim path is relevant.

The key points are:

• it does not drop to zero;
• it is not handled arbitrarily;
• it is a rule-based, verifiable, predictable on-chain behavior.

Put differently, OBTC tries to turn dormant-asset handling into protocol behavior that can be explained to users in advance rather than a vague long-run social consequence no one has modeled precisely.

5. Parameters and activation schedule (current implementation values)

OBTC uses staged activation rather than a single all-at-once switch. That is important because indexing, enforcement, hardening, and replay isolation do not all need to become mandatory at the same block height. Separating them allows state to be prepared before stricter validity rules become active.

5.1 Activation matrix across the three networks

Explanation:

• Fork Height: the height where OBTC enters its own rule domain.
• Expiry Index Start: the height from which expiry state is indexed and maintained.
• Expiry Enable: the point at which expiry spending constraints become active.
• REAP Hardening: the point where REAP input order and input caps become consensus-enforced.
• Replay Protection: the point where signature-domain isolation becomes consensus-enforced.

The presence of a distinct Expiry Index Start matters conceptually. It means the chain can begin tracking expiry-related state before every downstream consequence of that state becomes mandatory. This reduces the risk of activating strict reclaim logic without sufficient indexed context.

The staged design also lowers rollout risk. Expiry indexing can be observed. Expiry enforcement can then activate. REAP hardening can become stricter after the ecosystem has already exercised the basic reclaim path. Replay protection can then complete cross-chain isolation at the signature domain level. Each step narrows ambiguity without forcing every concern into the same activation event.

5.2 Expiry parameters

Notes:

• Mainnet 362,880 blocks equals 9! and is about 6.91 years;
• test networks use shorter windows to make validation and rehearsal faster.

These parameters should be read as a bundle rather than as isolated numbers. WindowBlocks controls the economic horizon. ListBatchLimit controls practical observability and scan safety. ReapMaxInputs controls how aggressively expired inventory may be processed in one system transaction. Together they determine not only protocol behavior but also how quickly reclaim state can move through the system under realistic block-building constraints.

Shorter test-network windows do not imply that mainnet should behave that way. They exist so that expiry, renewal, and reclaim can be rehearsed on human time scales rather than over many years.

5.3 Namespace Isolation parameters

• Network magic:
  • Main: 0x4F425443
  • Test: 0x4F544553
  • Reg: 0x4F524547
• Default port: 9527 / 19527 / 29527
• Bech32 HRP: obtc / obtct / obtcrt
• isolated address prefixes for P2PKH, P2SH, and witness formats
• isolated HD key versions
• BIP44 coin type: 20260 / 20261 / 20262

Implementation requirement: collisions are checked at startup, and the node must refuse to start if a conflict is detected.

Namespace isolation should be understood as a practical first line of defense. It reduces accidental cross-chain confusion before signature verification is even discussed. Different ports, address prefixes, HD versions, and coin types make it harder for operators, scripts, and wallets to silently treat OBTC and Bitcoin as interchangeable.

That does not replace replay protection. It complements it. Namespace isolation protects against misrouting, operator mistakes, and tooling confusion. Replay protection protects against signature reuse and cross-chain transaction validity. OBTC uses both because real systems fail in multiple ways, not only at the cryptographic layer.

5.4 Default REAP policy parameters

• Sort mode: Strict
• Mainnet max inputs: 256
• Mainnet weight budget: 200,000
• Tax ratio: 30%
• Dust threshold: 720 sat (6! = 720)

These defaults express a design preference for determinism, bounded resource use, and conservative block-template behavior. The tax ratio and dust threshold define the reclaim split and small-output behavior, while the input and weight limits bound how aggressively any single block may process expired inventory.

The practical effect is that reclaim happens under capacity constraints rather than through unrestricted sweeping. This matters both for fairness and for operational stability. Even if the expired backlog is large, it is processed through bounded, reviewable steps.

5.5 Default Auto-Renew parameters

• Enabled: false
• Interval: 30m
• Failure backoff: 15m (may be 0)
• Window: window_end <= blocks_to_expiry <= window_start
  • window_start = 52560
  • window_end = 25920
• MaxUtxosPerRun: 100
• MaxFeeRate: 5000 sat/KB
• MaxRenewAmountPerRun: 0 (unlimited)
• autorenewamount: when enabled, it must be greater than 0

These are wallet-side execution defaults, not consensus rules. That distinction matters. Consensus says when an output is expired. Auto-Renew says how a wallet process may decide to act before that state is reached.

The defaults are deliberately safety-oriented. Auto-Renew is off by default. It operates inside a defined window rather than on every output at all times. It has explicit limits for fee rate, candidate count, and optional budget. Failure backoff exists to prevent retry storms and to keep automation from becoming a source of self-inflicted instability.

6. UTXO lifecycle

The lifecycle model is the conceptual center of OBTC. Every later section - indexing, reclaim, wallet renewal, economics, and observability - becomes easier to understand once the lifecycle is treated as the primary object rather than the isolated event called "expiry."

6.1 The key formula

Let:

• W = WindowBlocks
• on mainnet W = 362,880 blocks (9!, about 6.91 years; often communicated externally as "about 7 years")

For any UTXO:

h_expiry = h_create + W

When h_tip >= h_expiry, that UTXO becomes expired.

This formula is intentionally simple. Expiry is not based on wallet heuristics, wall-clock timestamps, or price conditions. It is height-based. That makes it deterministic, portable across implementations, and easy to reason about in consensus terms.

It also clarifies that expiry is tied to the age of each UTXO, not to the age of a wallet, address, or account. A user may hold many outputs with different creation heights and therefore different expiry horizons. That is one reason wallet-side monitoring becomes important in practice.

6.2 Wallet-side status layers

To make the system legible, wallets usually present three states:

• ok: still far from expiry
• expiring: approaching expiry and should be handled
• expired: already expired

Note: ok and expiring are UX layers; the actual consensus question is simply whether the UTXO is expired.

That distinction matters because users and automation systems need more nuance than consensus does. Consensus only needs to know whether the ordinary spending path is still valid. Wallets need to know whether a UTXO is still comfortably safe, approaching a renewal boundary, or already beyond the ordinary path.

So the wallet vocabulary is intentionally richer than the protocol vocabulary. It gives users enough signal to act before the hard edge matters, but it should not be mistaken for an additional consensus state machine.

6.3 The two paths in the lifecycle

1. User path: renew before expiry and keep the asset active.
2. System path: after expiry, the asset can be processed by REAP rules.

This split is what makes OBTC more than a negative-interest metaphor. Active users are not expected to passively wait for reclaim. They are expected to maintain assets through normal spending or deliberate renewal, usually at a cost far below the reclaim tax.

The system path exists because a lifecycle model without an endpoint would not actually change the long-run treatment of dormancy. But the user path remains economically dominant for attentive holders. That asymmetry is intentional: the reclaim path is a backstop for neglected state, not the preferred steady-state experience for ordinary users.

6.4 A full example

• UTXO amount: 10,000,000 sat (0.1 BTC)
• after expiry and REAP:
  • tax = floor(10,000,000 x 30%) = 3,000,000 sat
  • refund = 7,000,000 sat
• if the input amount v is below the dust threshold, no refund output is created and the full amount is folded into tax.

The economic reading of this example is straightforward: the system does not erase the asset, but it does reclassify its value. Most of the value is returned into a fresh output under the original script, while a smaller share is redirected to the security budget that carried the dormant state.

The operational reading is equally important: the refund output is a new UTXO with its own lifecycle. In other words, REAP does not merely settle an expired output. It also regenerates a new output unless dust fold removes that path for very small values.

That regenerative property is part of what makes the "organic" label meaningful. The system does not end at reclamation. It loops value back into circulation under a new timer.

7. Expiry Index: how to track expiring assets efficiently

The lifecycle rule is easy to state and expensive to enforce naively. The chain cannot afford to rediscover expiry from scratch by repeatedly scanning the full live set. That is why expiry indexing is not an optional optimization. It is a structural requirement for making reclaim operationally feasible.

7.1 Why an index is mandatory

It is not acceptable to scan the entire historical set on every new block just to ask "what expired now?"
That is why a dedicated expiry index is required.

The reason is both obvious and fundamental. The UTXO set can be large, while the number of outputs that become relevant at a given height may be comparatively small. A protocol that required full-state scanning at every block just to identify candidates would turn a logically simple rule into an operational burden on every node and miner.

So OBTC shifts work from repeated global scanning into incremental maintenance. Expiry is computed once when outputs are created, persisted in an index, updated when outputs are spent, and scanned in ordered form only when needed. That is the difference between a lifecycle model that sounds elegant in prose and one that actually fits block-by-block operation.

7.2 Bidirectional mapping structure

At an implementation level, the index can be abstracted as:

1. OutPoint -> ExpiryKey
2. (ExpiryKey || OrderedOutPoint) -> empty

Benefits:

• fast deletion by looking up ExpiryKey from OutPoint, then deleting the composite entry,
• fast range scanning by walking composite keys grouped by ExpiryKey.

The forward mapping exists because spent outputs must be removed efficiently. Once an outpoint is consumed, the node needs to know where its expiry state lives without scanning multiple buckets to find it.

The composite scan index exists because reclaim is fundamentally an ordered scanning problem. It is not enough to know that an output expires at some height. The system also needs a deterministic way to walk expiring outputs in stable order for selection, pagination, and template construction. Storing one ordered composite-key entry per indexed UTXO lets the database perform the ordering work directly.

OrderedOutPoint matters because raw byte encoding is not guaranteed to match the desired lexicographic or human-readable order. Reversing txid bytes and using big-endian encoding for vout ensures that database iteration matches the intended deterministic ordering semantics.

An important implementation consequence follows from this layout: the reverse structure is not a giant "list value per expiry key." That would force large value rewrites and less efficient mutation behavior. The composite-key approach keeps update cost local and scanning behavior naturally ordered.

7.3 Block connection and rollback

• ConnectBlock: add new outputs into the index, remove spent inputs from the index;
• DisconnectBlock: restore the reverse state.

That keeps the index aligned with the active chain even under reorg.

The core discipline here is symmetry. Every live update path must have a rollback path that reconstructs the same indexed state the node would have had if the disconnected block had never been accepted. Without that property, expiry indexing would drift under reorganizations and eventually stop being a reliable source of reclaim candidates.

This is also why the index tracks its own notion of indexed tip height. Nodes need to know not only that buckets exist, but also what chain state those buckets correspond to. A correct expiry index is not merely a set of key-value pairs; it is a state summary attached to a particular active-chain tip.

Rebuild exists because live maintenance is not the only correctness path. If the index is missing, version-mismatched, corrupted, or explicitly reindexed, the node must be able to reconstruct expiry state from the underlying UTXO set. The correctness target is that live maintenance and rebuild arrive at the same effective indexed state for the same active chain.

7.4 Paged scanning and resumable queries

Suggested interface:

(fromKey, toKey, maxResults, startAfter)

• maxResults controls page size,
• startAfter supports resumable scans,
• suitable for large queries without returning excessive result sets in one response.

This is not only an RPC ergonomics choice. It is also an operational safety choice. Large reclaim-related scans can be expensive or long-running if the expired inventory is large. Pagination prevents the observation and planning layer from assuming that the entire relevant set must be loaded or returned in one step.

Because the scan index is ordered, cursor-based continuation is stable enough to support both operators and automated systems. A caller can resume from a known (height, outpoint) boundary without re-scanning from genesis or relying on unstable list offsets.

In practice, that means the expiry index supports more than reclaim construction. It also supports observability, planning, dry-run analysis, and operational dashboards that need to reason about the expiring set in manageable chunks.

8. REAP: the full rule set for system reclaim transactions

REAP is where the lifecycle rule becomes economically consequential. It is also where OBTC has to be most careful about determinism, resource control, and auditability. A reclaim system that is vague at transaction-construction time would invite abuse, divergence, or both.

8.1 What REAP is

REAP (Reclaim Expired Assets Protocol) is a block-internal system transaction:

• its purpose is to process expired UTXOs;
• it is not an ordinary user transaction template and does not rely on mempool relay.

That second point is essential. REAP is not meant to be a public mempool race among users, bots, or opportunistic builders. It is a miner-assembled system transaction that exists because the protocol permits expired outputs to be reclaimed under explicit ordering and accounting rules.

Treating REAP as block-internal sharply reduces pollution from fake system transactions, avoids turning reclaim into a noisy relay game, and keeps the reclaim path under the same deterministic constraints that already govern block-template assembly.

8.2 Minimum conditions for validity

For a REAP transaction to be valid, at least the following must hold:

• all inputs must be expired UTXOs;
• the transaction structure must match REAP characteristics;
• marker consistency checks must pass;
• after activation, hardening constraints must also hold.

These conditions exist because REAP is powerful by design. It spends outputs without the ordinary owner-signature path. That means the validation surface must be narrower and more explicit than it is for normal user transactions.

In other words, the protocol does not grant miners a vague right to "take old coins." It grants them the ability to build one very specific kind of system transaction under a tightly reviewed rule set. Every structural check narrows the gap between "system reclaim" and "arbitrary value extraction."

8.3 Tax, refund, and dust rules

For each input amount v:

• tax = floor(v x 30 / 100)
• refund = v - tax

Dust fold rule: the current implementation checks the input amount. If 0 < v < dust_threshold, then:

• refund -> 0
• tax -> v

The split is intentionally simple. A more complex ratio schedule might allow more policy tuning, but it would also make the system harder to reason about and easier to politicize. OBTC chooses a single protocol-level ratio so that users can compare renewal cost against reclaim loss with minimal ambiguity.

Dust fold exists for the same reason Bitcoin-like systems generally care about dust: tiny outputs that are uneconomic to spend are not a real continuation of ownership in practice. The current consensus rule uses an input-value cutoff, so a below-threshold expired input is folded fully into tax instead of manufacturing a formal but uneconomic refund output.

8.4 Marker binding

The marker format is:

REAP:<height>:<count>:<digest>

Consensus checks:

• height must match,
• count must match,
• digest must match.

The marker is a compact binding device. It gives the validating node a protocol-visible way to confirm that the transaction context, selected inputs, and claimed structure all line up with what the system transaction is supposed to represent.

Without a binding mechanism like this, REAP would be harder to distinguish and audit as a system action. The marker makes the transaction self-describing enough to tighten validation and reduce ambiguity in tooling and review.

8.5 Hardening after activation

REAP inputs must follow canonical order:

expiry -> amount -> outpoint

and also respect the input ceiling ReapMaxInputs.

Canonical ordering matters because it removes degrees of freedom that miners could otherwise use for preferential harvesting or implementation-specific behavior. If every builder sorts the same way, the reclaim path becomes substantially more predictable and less exploitable.

The input ceiling matters because reclaim must coexist with ordinary block construction. Even if the expired backlog is large, any single block should only process a bounded portion of it. That keeps reclaim from crowding out the rest of the transaction market or creating unstable template behavior.

8.6 Coinbase accounting

Define:

• ReapTax(h): the total REAP tax collected in the block at height h

The coinbase upper bound is:

BaseSubsidy(h) + Fees(h) + ReapTax(h)

ReapTax follows the same maturity rule as coinbase.

This is the accounting bridge between reclaim and miner revenue. REAP tax is not an off-ledger concept. It becomes part of the same bounded settlement logic that already governs subsidy and fees.

Applying coinbase maturity to REAP tax is also conceptually clean. The reclaim tax is part of block reward settlement and therefore inherits the same settlement discipline rather than becoming a special fully liquid side channel.

8.7 Invariant

The following must always hold:

sum(inputs) = sum(refunds) + sum(tax)

This is the core audit and regression invariant.

It is worth emphasizing because invariants are where complex systems stay legible. As reclaim rules, dust fold, canonical ordering, and coinbase accounting evolve, this conservation rule remains an anchor. If it fails, the implementation is wrong regardless of how persuasive the rest of the logic sounds.

9. Replay Protection: how cross-chain replay is prevented

Cross-chain safety is not just a signing detail. A forked system must defend against both accidental operator confusion and deliberate signature reuse. OBTC therefore treats replay protection as a layered system rather than as one isolated bit flag.

9.1 Two defensive layers

1. Namespace Isolation at the address, port, HD, and coin-type level.
2. Replay-protected sighash domain at the signature-message level.

These layers solve different problems. Namespace isolation makes it harder to connect to the wrong chain, derive addresses under the wrong assumptions, or send value to an address format that looks deceptively familiar. Replay-protected sighash semantics stop valid signatures on one chain from remaining valid on the other chain after activation.

If OBTC only used namespace isolation, cross-chain signature reuse would remain a risk. If it only used replay-protected signatures, users and tooling could still make preventable operational mistakes before signing. Using both closes both the ergonomic and cryptographic gaps.

9.2 Implementation details

• replay bit: 0x40
• domain tags: separate tags for Legacy, Witness, and Taproot paths

The high-level point is that replay protection is not treated as a single monolithic script-path rule. Different signing modes need explicit domain separation so that replay isolation actually covers the transaction forms the system intends to support.

That is why the whitepaper describes replay protection as a signature-domain design rather than as a wallet warning. The system must ensure that the message being signed is chain-specific after activation, not merely that wallets try to be careful.

9.3 Activation gate

• before activation: compatibility semantics may continue to work;
• after activation: any signature missing replay-protected semantics fails directly.

The activation gate exists for rollout discipline. It allows chains and tooling to move from compatibility expectations toward full isolation without pretending that both states are the same. Before activation, the system can preserve transitional behavior. After activation, the boundary becomes hard.

This also improves review clarity. Operators know when replay-protected semantics are merely recommended and when they are mandatory. That is better than a vague "replay protection is generally important" claim that leaves the actual enforcement moment ambiguous.

9.4 Path coverage

• Legacy
• SegWit v0
• Taproot, both key path and script path

Coverage matters because partial replay protection is not full replay protection. If some signature paths were isolated and others were not, the remaining gap would become the most interesting path for mistakes or abuse.

OBTC therefore states path coverage explicitly. The goal is not to say replay protection exists in spirit, but that the relevant signing families are brought under the same chain-specific isolation model.

10. Node operation model

The reclaim and renewal model has implications beyond consensus. It changes what kinds of node roles are useful, what must be retained locally, and what trust model operators can accept for synchronization.

10.1 Pruned Full Node vs Archive Node

• Pruned Full Node: keeps the full UTXO set, a rolling window of block bodies, and all block headers.
• Archive Node: keeps the full historical chain and all transaction bodies.

OBTC does not require every participant to become a full-history historian. A pruned full node can still validate the chain as long as it retains the live set and the data required for ongoing validation. Archive nodes remain valuable for audit, research, and historical query, but they are not the only legitimate full participants.

That distinction matters because lifecycle-aware systems should not quietly assume that the answer to state-management complexity is "everyone stores everything forever." OBTC tries to make reclaim compatible with differentiated node roles instead of using reclaim as an excuse for universal archival retention.

10.2 Invariants

• history is never rewritten;
• pruning changes storage retention, not consensus verifiability.

Those invariants keep the design from collapsing into selective memory. Pruning is a storage policy, not an excuse to alter history. Likewise, reclaim changes the spendability state of outputs under explicit rules; it does not retroactively erase the historical fact that those outputs once existed.

This distinction is important for both audit and trust. Users should be able to say: the system changed the current legal status of a UTXO, but it did not falsify the chain's historical record.

10.3 Snapshot synchronization and UTXO commitments

Initial sync can be accelerated through snapshot import plus proofs plus multi-source consistency checks.
At least k independent sources should agree before an import is trusted.

Snapshot-assisted sync is an operational tool, not a suspension of verification discipline. The point is to reduce time-to-participation without replacing verification with blind trust in a single snapshot publisher.

In a lifecycle-aware chain, this becomes even more important because nodes may care not only about the current UTXO set but also about the integrity of the expiry-related state that interacts with it. Multi-source agreement, proofs, and consistency checks reduce the chance that a poisoned snapshot becomes a hidden consensus liability.

11. Wallet capability closure

Protocol rules alone are not enough for a lifecycle system. Users need interfaces that turn expiry from an abstract property into an actionable operating picture. That is why the wallet layer in OBTC is not an optional convenience add-on; it is part of how the broader design remains usable.

11.1 obtc.getexpiry

Returns the key risk fields for expiry management:

• outpoint
• amount
• create height
• expiry height
• blocks_to_expiry / days_to_expiry
• status
• dust_risk

This RPC is the observation surface for lifecycle risk. It allows users, operators, and automation systems to ask not only "what do I own?" but "what is approaching a maintenance boundary?" That is a materially different question from ordinary balance reporting.

The inclusion of both height-based and user-facing fields matters. Height and blocks-to-expiry anchor the answer in protocol reality. Status and dust-risk style fields make the answer usable for wallets and dashboards. In effect, obtc.getexpiry is where the lifecycle model becomes inspectable rather than implicit.

11.2 obtc.renew

Supports explicit renewal by outpoint, with parameters including:

• amount
• target address (optional)
• max fee rate (optional)
• minconf (optional)

It returns a transaction summary such as txid, number of inputs and outputs, and fee rate.

The important design point is that renewal is an explicit first-class action, not an obscure side effect of some unrelated transaction path. A user or operator can deliberately choose which outputs to renew, under what fee assumptions, and toward which target address.

That directness matters for safety. If renewal is meant to be the rational active-user alternative to reclaim, then it has to be visible, auditable, and easy to reason about. obtc.renew is the narrow manual path that provides that clarity.

11.3 renewall

Supports:

• status or window-based filtering,
• dry-run mode,
• interval/runs scheduling.

renewall exists because lifecycle maintenance quickly becomes an operational problem rather than a one-output problem. Once users or operators manage many outputs, the relevant question is not "can I renew one UTXO?" but "can I review and manage renewal work as a bounded batch process?"

That is why filtering, dry-run behavior, and scheduling matter. The tool is meant to support repeatable maintenance with previewability, not just mass submission. In practice, it forms a bridge between one-off manual renewal and continuous automated policy execution.

11.4 Auto-Renew scheduler

Features:

• periodic execution,
• window-based filtering,
• candidate count limit,
• fee-rate ceiling,
• failure backoff,
• per-run budget control.

The goal is automated risk mitigation within explicit safety boundaries.

This is an important boundary in the design. Auto-Renew does not change consensus and does not hide lifecycle rules from the user. It sits above consensus as a wallet-side service that tries to keep attentive users from drifting into reclaimable state because of pure operational neglect.

The safety boundaries are part of the design, not a footnote. Candidate limits, fee ceilings, budgets, and backoff keep the scheduler from turning normal protective automation into runaway spending or repeated failure loops. Automation without these controls would weaken rather than strengthen the lifecycle model.

11.5 The wallet automation direction

OBTC has a natural extension path at the wallet layer: make lifecycle asset management observable, previewable, and safe to automate.

The reason is straightforward:

• expiry risk has to be monitored continuously, not remembered manually once every few years;
• renewal should be previewable before signing or broadcasting;
• batch scheduling, budgets, and failure backoff are operational controls, not consensus rules;
• audit trails are essential when renewal is delegated to software or repeated operator workflows.

That is why the interface and wallet layer should prioritize:

• capability-based authorization instead of all-or-nothing unlock semantics,
• a controlled pipeline of preview -> approve -> sign -> publish,
• separation between a watch-only planner and an isolated signer,
• event-driven alerts for expiry, failure, and policy conditions,
• default auditability through operation metadata and policy metadata.

The deeper point is that lifecycle asset management naturally produces tasks that software can monitor, schedule, preview, and record more reliably than humans can do purely from memory. That is an operations claim, not a consensus claim.

That is also why the wallet/product layer is the right place for this direction. The chain only needs deterministic validity rules. Planning, authorization, staged signing, and automation policies belong above the chain in systems that can evolve faster and preserve clearer operator control.

This is a wallet and product-layer direction, not a new consensus rule.

12. Economics and game theory

The economic argument for OBTC should be read carefully. It is not a guarantee that one precise budget outcome will occur every year. It is a claim that the protocol creates a structurally different revenue path and incentive environment than a system that treats dormant outputs as permanently inert.

12.1 Long-term security budget estimate

Let mainnet W = 362,880 blocks. Using 52,560 blocks per year:

$$
T = W / 52,560 \approx 6.91 \text{ years}
$$

For a post-REAP retention ratio \rho = 0.7:

$$
p = -\ln(\rho) / T \approx 5.2\% \text{ per year}
$$

If the dormant-supply ratio is L:

$$
B \approx L \cdot p
$$

When L \in [20\%, 30\%], then B is roughly 1.0% - 1.6% per year.

These formulas are best understood as an annualized transformation of the reclaim rule, not as a promise that actual realized miner revenue will appear as a smooth yearly percentage. T describes the time window implied by mainnet parameters. \rho describes the retained share after reclaim. p is the equivalent annualized decay rate implied by that retention over that window. B is a rough annualized inflow estimate once a dormant-supply assumption is introduced.

The value of the estimate is comparative, not prophetic. It shows that the reclaim rule is not economically trivial. Under plausible dormant-supply assumptions, the reclaim path can represent a material security-budget input. That is the relevant conclusion even if actual realized flows are uneven in time and dependent on backlog composition.

12.2 Incentives for compliant users

When the cost ratio of renewal \phi is far below the 30% tax rate, rational users prefer proactive renewal.
That means larger UTXOs will usually be actively maintained, while smaller UTXOs are more constrained by dust economics.

This is the central active-user incentive story. For a user who still controls keys and notices the approaching window, renewal usually dominates reclaim by a wide margin. The protocol therefore does not rely on altruism to encourage maintenance. It relies on a simple cost comparison.

That comparison is not uniform across all outputs. Large-value outputs are easiest to justify renewing because the fee share is small relative to value at risk. Small outputs live closer to the dust boundary and can become less attractive to manage individually. That is why consolidation, batching, and wallet-side scheduling matter so much in practice.

12.3 MEV suppression

Deterministic ordering plus resource ceilings compress the room for preferential harvesting and reduce strategic noise.

The purpose of canonical ordering is not only aesthetic fairness. It also narrows the space in which miners or builders could otherwise prioritize especially attractive expired outputs while deferring less attractive ones. If reclaimable inventory must be processed in deterministic order within bounded inputs and weight, the reclaim path looks less like discretionary extraction and more like scheduled inventory processing.

No deterministic rule removes every strategic consideration in block construction, but it can substantially compress the value of cherry-picking. That is the sense in which OBTC aims to suppress MEV-like behavior here: by reducing degrees of freedom in selection, not by claiming to abolish miner incentives entirely.

12.4 Immediate expired backlog from historical inheritance

OBTC does not start from an empty genesis. It inherits Bitcoin's historical UTXO set.

Let:

• F = Fork Height
• A = Expiry Enable
• W = WindowBlocks

Then every historical UTXO satisfying:

h_create + W <= A

and still unspent at activation immediately enters the expired backlog once expiry is enabled.

Using the current mainnet parameters:

• F = 950,000
• A = 952,016
• W = 362,880
• therefore the threshold is h_create <= 589,136

This means the system does not have to wait a full 6.91 years before the first large historical dormant set becomes processable.
Once the activation height is reached, the chain already contains a pre-existing candidate pool.

Important nuance:

• the backlog exists immediately,
• but it is released gradually, block by block, because each REAP transaction is still constrained by ReapMaxInputs and the weight budget,
• so it behaves more like a long inventory processed over many blocks than a one-block purge.

This inheritance effect is one of the strongest differences between OBTC and a hypothetical clean-sheet chain that introduced the same reclaim rule from genesis. A clean-sheet chain would have to wait through its full expiry window before reclaim became economically meaningful. A Bitcoin-derived fork inherits age immediately.

That does not mean the full inherited backlog becomes miner revenue overnight. The protocol still limits how much reclaim can be processed in a block. But it does mean the system may begin life with economically relevant dormant inventory already present, which changes the early security-budget story substantially.

12.5 The economic flywheel: why it may self-start

The potential flywheel in OBTC is not a single narrative; it is a linked set of reinforcing loops:

1. historical dormant outputs create an immediate backlog;
2. REAP gradually turns that backlog into tax flow;
3. tax flow strengthens miner revenue and security-budget resilience;
4. a more stable security expectation improves willingness to integrate among miners, wallets, and platforms;
5. more integration increases renewal, transfer, and asset-management activity on-chain.

The important phrase here is "may self-start," not "must self-start." The flywheel is an argument about reinforcing structure, not a certainty about market reception. Social resistance, poor tooling, weak miner participation, or thin integration could all reduce the effect.

Still, the structure is materially different from that of a chain that hopes fee pressure alone will one day solve security-budget concerns. OBTC creates a path in which dormant inventory, renewal behavior, and wallet/product integration can all contribute to a self-reinforcing system if adoption conditions are good enough.

13. Security model and threat analysis

The security model of OBTC is not only about cryptography. It also includes ordering discipline, system-transaction isolation, rebuild correctness, operator mistakes, and cross-chain confusion. A lifecycle system is only as credible as the boundary conditions that stop reclaim from becoming ambiguous or exploitable.

13.1 Typical threats

• forged markers,
• reordered REAP inputs,
• oversized input sets,
• cross-chain replay,
• fake system transactions injected toward the mempool,
• poisoned snapshots,
• reorg-driven arbitrage.

These threats span different layers on purpose. Some are local transaction-validity problems. Some are block-construction problems. Some are operational problems. Some are sync or tooling problems. The design therefore cannot rely on one defense primitive and call the system secure.

13.2 Defensive lines

• marker consistency checks,
• canonical order,
• input caps plus weight budgets,
• replay-protected sighash domains,
• mempool policy isolation,
• multi-source snapshot validation,
• coinbase maturity constraints.

Taken together, these defenses make reclaim narrower, more auditable, and less discretionary. Marker checks bind context. Canonical order and resource caps reduce preferential selection freedom. Replay protection isolates signature domains. Mempool isolation prevents fake-system-transaction noise. Snapshot validation reduces the risk of poisoned acceleration paths. Coinbase maturity keeps reclaim tax inside ordinary reward settlement discipline.

The overall security philosophy is simple: if a rule is powerful, narrow the circumstances under which it can operate and add explicit checks at every layer where ambiguity would otherwise accumulate.

14. Operations and observability

A lifecycle-based monetary system is not only judged by whether the rules are correct in theory. It is judged by whether operators can see the system's state, detect drift, and respond before local failures become user-visible incidents. That is why observability is not a cosmetic appendix here.

14.1 Suggested metrics

Consensus

• expired spend rejection count,
• REAP non-expired spend rejection count,
• replay-protection violation count.

These metrics tell you whether the node is encountering rule-boundary violations and what kind. They are useful not only for security monitoring but also for detecting wallet or integration software that is still reasoning with stale assumptions.

Mining

• template build attempts with REAP,
• REAP append success rate,
• reserved weight utilization,
• REAP tax contributed to coinbase.

These metrics describe whether the reclaim path is working operationally in template construction rather than merely existing in code. For example, a low append success rate with a rising expired backlog suggests not an economic problem in the abstract, but a construction or policy bottleneck that needs investigation.

Wallet

• auto-renew candidate count per run,
• auto-renew success/failure ratio,
• backoff activation count,
• per-run budget truncation count.

14.2 Suggested alerts

• N consecutive rounds of auto-renew failure,
• sustained REAP append success below threshold,
• expiring backlog continuing to rise.

14.3 Implementation suggestions

1. consensus layer: end-to-end tests for Expiry, REAP, and Replay Protection
2. node layer: regression for both pruning and archival modes
3. wallet layer: expiry warnings, manual renewal, and auto-renew stability tests
4. mining layer: block-template boundary tests and stress tests
5. test networks: accelerated-expiry rehearsals, for example around seven days
6. tooling layer: public dashboards and anomaly-tracking reports

15. Governance and upgrades

Governance principles:

• core constants should remain as stable as possible,
• adjustable parameters must have delayed effect and explicit activation heights,
• upgrade flow should be mechanical, transparent, and reproducible,
• discretionary space should be minimized.

16. Mathematical appendix

• mainnet time window: T = W / 52,560, where mainnet W = 362,880
• annualized decay: p = -ln(\rho) / T
• annual security inflow: B = L x p
• equal-budget transformation: \rho' = exp(-pT')
• reverse solution for target budget: \rho = exp(-(B_target x T)/L), \tau = 1 - \rho

17. Key KPIs

• ReapTax / MinerRevenue on an annualized basis,
• supply at risk (expiring within 90 days),
• renewal success rate,
• average and quantile volatility of REAP counts per block,
• number and distribution of archive nodes,
• auto-renew adoption rate and complaint rate.

18. Legal and compliance notice

OBTC is an independent chain and is not the same as Bitcoin.
The expiry and reclaim mechanism may be interpreted in different jurisdictions as a protocol fee, a negative interest mechanism, or a redistribution rule applied to dormant assets. Exchanges and custodians should design their internal processes and user disclosures accordingly.

19. Glossary

This section exists to lower the reading barrier. If a term feels unfamiliar, check here first.

20. Frequently asked questions

Q1: What happens if I do nothing?

If your UTXO remains unmoved long enough to reach expiry, it enters the expired state.
After that it is no longer spent through the ordinary path and may be processed by REAP: 70% refund and 30% tax to the security budget.

Q2: Does the asset get taken away immediately at the expiry point?

No. Expiry means the UTXO enters a state where the system is allowed to process it.
The exact block where REAP happens depends on whether the block template selects that input in that round.

Q3: How do I avoid REAP?

Renew before expiry.
You can do this manually with obtc.renew, or use batch and automated renewal strategies.

Q4: Why is there a 30% tax?

This is part of the protocol-level security-budget design.
It routes part of dormant asset value into miner income and strengthens long-term budget resilience. For active users, renewal is usually much cheaper than 30%.

Q5: Are replay protection and address-prefix isolation redundant?

No. They work at different layers:

• address, port, HD, and related namespace isolation prevent accidental misconnection and misdirected transfers;
• signature-domain isolation prevents cross-chain signature reuse.

Both are required for a complete defense.

Q6: Why does REAP not enter the mempool?

Because it is a system transaction, not an ordinary user transaction.
Putting it into the mempool would invite fake-system-transaction pollution and resource abuse. The current model is block-template construction plus in-block execution.

Q7: What happens to small UTXOs?

If the input amount is below the dust threshold, dust fold is triggered: no refund output is created, and the full input value becomes tax. That avoids creating on-chain garbage outputs.

Q8: I only care about engineering implementation. Which sections matter most?

Recommended order: Section 5 (parameters) -> Section 8 (REAP) -> Section 9 (Replay Protection) -> Section 11 (Wallet) -> Section 14 (Operations).

Q9: Does this rule set make the system too complex?

The complexity mainly comes from making long-term risk explicit.
OBTC's approach is to move that complexity into rules and tooling earlier, instead of leaving the system to rely on manual after-the-fact remedies.

Q10: If parameters need to change in the future, how do we avoid arbitrary changes?

Parameter upgrades should follow the principle of delayed effect plus fixed activation height plus a transparent signaling process. The main objective is to reduce governance uncertainty and market expectation shocks.

Q11: Why call it Organic Bitcoin?

Because it treats assets as part of a system with a lifecycle rather than a permanently static pile of state. UTXOs move through creation, use, dormancy, expiry, reclaim, and regeneration. "Organic" points to a living system, not a food metaphor.

Q12: Why does the whitepaper emphasize wallet automation?

Because the wallet layer in OBTC naturally involves continuous expiry monitoring, batch renewal, policy execution, and audit traces. These are wallet and operator concerns, not consensus rules.

21. Conclusion

The core of OBTC is not novelty for its own sake. It is the executability of the rule set.

Its distinctiveness does not mainly come from brand-new cryptographic primitives.
It comes from combining known mechanisms into a working economic system.

OBTC puts four questions into one coherent architecture:

1. how long-dormant assets should be handled,
2. how miner security budgets can stay resilient over long time horizons,
3. how cross-layer systems can remain predictable, operable, and explainable,
4. how wallet software and operators can manage renewal safely within explicit boundaries of authorization, renewal, and audit.

The only real success criterion for this whitepaper is:

Are the rules clear enough that independent teams can implement them separately and still converge on the same chain behavior?

22. License

This document is recommended for publication under CC BY 4.0.
Reference implementations may use permissive licenses such as MIT.

End of Whitepaper V1.0 (Implementation-Aligned, Extended Readable Edition)