Learn OBTC

Learn OBTC: active ownership, lifecycle rules, and REAP.

OBTC is not designed to convince everyone. It is designed for people who believe long-term monetary sustainability requires active ownership, explicit state costs, and a security budget that does not depend entirely on future transaction fees.

This article keeps the core argument in one place. The goal is not to multiply slogans or make readers jump across separate pages. The goal is to explain OBTC in plain language, with enough precision that a reader can accept it, reject it, or inspect the implementation.

Static scarcity created Bitcoin. Lifecycle sustainability is the question OBTC explores.

1. The problem is not only lost coins

Bitcoin made digital ownership concrete: if you control the key, you control the coin. That was the right first problem to solve. But over very long horizons another question appears. What should a chain do with value that has gone silent for years, possibly forever, while the network keeps carrying the state?

One answer is to do nothing. Treat every dormant output as permanently valid, even if no human can spend it, no wallet watches it, and no future owner can recover it. That answer is simple and familiar. It is also a policy choice. It says that permanent state occupation should have no native time cost and that abandonment should be indistinguishable from patient holding at the protocol level.

OBTC explores a different policy. It treats ownership as durable but not completely passive. A holder has a long lifecycle window. During that window the holder can move or renew. If nobody acts for long enough, the output crosses a lifecycle boundary and can be processed by REAP under deterministic rules.

2. What “organic” means here

“Organic” is not a branding claim that the system is natural or morally superior. It is a shorthand for lifecycle thinking. In a living system, things can be maintained, renewed, neglected, recycled, or returned to circulation. OBTC applies that idea to monetary state.

The static model says an output can remain silent forever without consequence. The lifecycle model says that time matters. If value is actively stewarded, the holder can keep it active. If value is abandoned beyond a very long window, the system eventually stops pretending that silence and stewardship are the same thing.

This is the core philosophical break from Bitcoin. Most forks change block size, throughput, governance, or economics around the edges. OBTC changes the treatment of time. It is for people who believe monetary systems should remain alive.

3. The lifecycle rule

At a high level, each UTXO has an expiry height. Before expiry, the ordinary path is simple: spend it or renew it. Renewal resets the lifecycle without requiring the owner to transfer the coin to someone else. Wallets are expected to make this visible through expiry inspection, warnings, and renewal tools.

After expiry, ordinary spending is intentionally closed. The output becomes eligible for REAP. REAP is the reclaim path: miners can include a deterministic reclaim transaction that processes expired outputs, routes a refund share back through the designed refund path, and routes a security-budget share to support the live proof-of-work network.

The important distinction is that expiry is not meant to be a surprise trap. The rule only stays defensible if the window is long, the state is inspectable, renewal is practical, and the reclaim path is constrained by consensus rules rather than operator discretion.

4. Why this is not just arbitrary taking

The strongest objection is obvious: if a system can process old coins after non-renewal, is that confiscation by another name? OBTC’s answer depends on boundaries. A vague maintenance power would be dangerous. A deterministic lifecycle rule is different only if users can see it before it matters, act before expiry, and verify the consequences after expiry.

A deeper objection is that OBTC chooses continuing human action, which may look closer to a use right than ownership. OBTC should not answer by pretending its model is identical to Bitcoin’s. Bitcoin’s ownership model can be summarized as private-key control equals indefinite ownership. OBTC’s ownership model is different: private-key control plus long-cycle maintenance equals continuing ownership.

In OBTC, ownership is not a one-time static condition. It is a long-duration claim maintained through key control and lifecycle renewal. OBTC does not hide this difference. It is the point of the system.

That is not a simple downgrade from ownership to use right. It is a philosophical choice between static ownership and lifecycle ownership. The lifecycle model only remains defensible if renewal windows are long, renewal is practical, and post-expiry REAP behavior is deterministic, bounded, and auditable.

Confiscation usually means discretionary seizure, ownership reassignment, or arbitrary control over another holder’s property. OBTC’s intended rule is narrower. It does not give an operator a button to freeze or redirect funds. It defines a long-dormancy state transition: active outputs can be renewed; expired outputs can be processed through REAP; accounting must follow the protocol.

The 30% security-budget share is still controversial. It should be controversial. The claim is not that every tax-like rule is fair. The claim is that a proof-of-work chain with permanent state and declining subsidy needs an explicit long-run security-budget story, and abandoned value is one possible input into that story.

The refund path matters because the design is not trying to erase the owner’s history completely. It is trying to price very long dormancy while avoiding a pure seizure model. If the refund and accounting rules are opaque, discretionary, or easy to manipulate, the argument fails.

5. What critics are right to worry about

Critics are right to worry that “maintenance” can become a soft word for control. They are also right to worry about user confusion. A lifecycle system becomes unacceptable if users cannot see expiry, cannot renew in practice, or discover the rule only after losing ordinary spend eligibility.

That is why OBTC needs more than consensus code. It needs wallet surfaces that show expiry clearly, renewal commands that can be tested, batch renewal for operational users, logs and evidence for failure cases, and public documentation that does not hide the trade-off.

There are hard red lines. No hidden rule changes. No discretionary ownership transfer. No opaque REAP accounting. No silent wallet experience. No marketing that suggests passive holders can ignore lifecycle forever.

6. Four review themes OBTC must answer

Four issues should stay visible in the public explanation because they decide whether OBTC is a disciplined lifecycle system or an accidental source of new power.

REAP ordering and MEV resistance

REAP creates a protocol-level value event, so ordering cannot be miner preference, mempool bidding, or an opportunistic sweep. Candidate selection, input caps, accounting, and ordering must be deterministic enough for full nodes to validate and narrow enough to reduce MEV and reorg incentives.

UTXO expiry index and state-bloat control

A lifecycle rule needs an expiry index that can be rebuilt, rolled back across reorgs, and scanned under bounded work. OBTC must prevent dust or mass-output patterns from becoming a future indexing burden or a delayed REAP workload attack.

Renewal safety and wallet automation risk

Renewal makes active ownership practical, but automation is not a substitute for safety. Manual renewal must remain visible and auditable; batch and auto-renew paths need previews, budgets, backoff, logs, and failure boundaries so wallet bugs do not become systemic loss events.

Lifecycle ownership philosophy

OBTC's ownership model is private-key control plus long-cycle maintenance. This is not hidden as an implementation detail; it is the philosophical core. The system is only honest if it states that lifecycle ownership differs from Bitcoin's static ownership model and lets readers reject that choice clearly.

7. The wallet layer is part of the monetary design

In a lifecycle system, the wallet is not just a convenience layer. It is the way a human understands time. The wallet must answer practical questions: which outputs are safe, which are near expiry, which are already expired, what can be renewed, what cannot be renewed, and what action will be published on-chain?

The current OBTC wallet direction already reflects that. The testnet-facing surfaces include expiry inspection, manual renewal, and batch renewal. Auto-renew remains a controlled automation path rather than a default promise. Expired UTXOs are intentionally not renewable through the ordinary active-holder path; that fail-closed behavior is part of the design, not an accident.

This is why the project cannot be judged only by the philosophy. The operational question is whether users and reviewers can actually inspect, renew, test failure cases, and reproduce the evidence.

8. Why OBTC may bootstrap

OBTC does not need everyone to accept the thesis before anyone has a reason to look. The cold-start argument is simple: several groups can inspect the system with different incentives before a mature network effect exists.

BTC holders

BTC holders do not lose BTC by paying attention to OBTC. The question is narrower: does a Bitcoin-derived lifecycle system create optional relevance or value discovery worth observing? A holder can reject that thesis without giving up Bitcoin ownership.

Miners

If miners support OBTC, REAP and ordinary fee flow may create an additional reward surface. This is not a guaranteed miner-revenue product. It is a reason for miners and operators to measure whether the network has a useful extra security-budget path.

Active OBTC holders

Active holders do not need to wait for REAP. If they still control keys and the wallet surfaces expiry clearly, periodic renewal can preserve long-term ownership at a cost far below being reaped.

Critics

Criticism is not noise. It helps define the boundary between a narrow lifecycle rule and unacceptable discretionary control. It also clarifies the philosophical split between permanent-state absolutism and lifecycle-aware monetary design.

That does not mean the network must bootstrap. The thesis depends on working software, mining participation, user understanding, credible claim flows, and enough market or social interest to keep the loop alive.

9. What OBTC is not

  • OBTC is not a Bitcoin replacement claim.
  • OBTC is not a guaranteed miner revenue product.
  • OBTC is not production financial infrastructure yet.
  • OBTC is not discretionary confiscation.
  • OBTC is not for people who want assets that require zero maintenance forever.

10. What would make the proposal fail

The proposal fails if lifecycle maintenance becomes discretionary control. It fails if users cannot renew reliably. It fails if REAP accounting cannot be independently checked. It fails if REAP ordering creates a new MEV surface, expiry indexing becomes a state-bloat liability, wallet automation creates systemic renewal failures, or lifecycle ownership is marketed as identical to Bitcoin's ownership model. It fails if the security-budget story becomes a marketing claim instead of a measurable rule. It fails if the project treats criticism as a messaging problem instead of a design constraint.

It also fails if the website explains the idea through too many disconnected pages. The idea is already difficult enough. The public surface should make the reader do less navigation, not more.

11. Short version

Bitcoin made digital scarcity possible. OBTC asks whether digital scarcity can remain sustainable over centuries. Its answer is a lifecycle rule: renew before expiry, fail closed after expiry, process long-dormant outputs through deterministic REAP, and make the security-budget and refund accounting visible enough to test.

The idea is not safe because it uses softer words. It is only defensible if REAP ordering resists MEV, expiry indexes remain bounded, renewal automation is safe, and lifecycle ownership is stated honestly. That is the standard the implementation and testnet evidence should be judged against.


Next reading: use the external review themes for open pressure-test questions; the REAP design notes for ordering, caps, accounting, MEV, and state-bloat risks; the whitepaper for protocol detail; the wallet page for current wallet surfaces; and the status page for testnet evidence and release boundaries.