deviant/BCH_Token_Economy_Concept_Paper.md

BCH Token Economy Platform

Concept Paper — Internal Reference Document

Version 0.1 — Pre-Implementation Draft

---

This document describes a proposed system. It is an internal reference for guiding implementation. Claims marked as [PROPOSED] describe design intent not yet validated by working code. Claims marked as [ESTABLISHED] describe capabilities that exist on BCH mainnet today.

---

1. Introduction

Bitcoin Cash was designed as a peer-to-peer electronic cash system. Its base protocol — adaptive block sizes, low transaction fees, UTXO model, and Simplified Payment Verification — provides a foundation capable of supporting global transaction volumes without reliance on second-layer solutions or sidechains. This is consistent with Satoshi Nakamoto's original design intent as documented in the Bitcoin whitepaper and in direct communications from 2008 to 2010.

This paper proposes a token economy platform built entirely on the BCH base layer. The platform introduces a novel token standard with properties that do not exist in any current token ecosystem. The core philosophical principle distinguishing this system from all existing token standards is stated precisely:

BCH satoshis function as a mathematical unit of account — a unit of divisibility — not as a market price mechanism. The protocol layer defines how tokens divide into smaller units. What tokens trade for in secondary markets is a separate concern that the protocol neither enforces nor follows.

This distinction makes the protocol permanently stable, infinitely scalable within BCH's design parameters, and completely independent of market conditions that would otherwise introduce complexity, oracle dependency, and trust requirements into every layer of the system.

---

2. Problems With Existing Token Systems

2.1 Comparison of Existing Approaches

Property	ERC-20 (Ethereum)	SPL (Solana)	SLP (BCH)	SmartBCH	This System
On-chain BCH/ETH/SOL backing	None	None	None	None	Yes — always
Base layer enforcement	EVM contracts	Runtime	None — indexer only	EVM sidechain	CashScript — [PROPOSED]
Protocol swap without counterparty	No	No	No	DEX required	Yes — open mint tokens [PROPOSED]
Guaranteed floor value on issuer failure	No	No	No	No	Yes [PROPOSED]
Custodial bridge required	No	No	No	Yes — failed 2022	No
Whitepaper-aligned scaling	No	No	Partial	No	Yes
Current status	Active	Active	Abandoned	Troubled	Proposed

2.2 Specific Failures

Ethereum ERC-20: Tokens have zero ETH backing. If an issuer disappears, token holders have no recoverable on-chain asset. Gas fees make microtransactions economically unviable at base layer. Layer 2 solutions introduce bridge trust assumptions Satoshi explicitly rejected. Oracle dependency required for any price-sensitive operation.

Solana SPL: Multiple full network outages demonstrate infrastructure immaturity. Validator concentration creates centralization risk. Tokens have zero SOL backing. Younger infrastructure with less battle-tested security.

SLP on BCH: Tokens created from nothing with no BCH backing. No contract enforcement at base layer — token rules enforced only by a centralized indexer. Tokens accidentally burnable when sent to non-SLP wallets. Abandoned due to these fundamental limitations.

SmartBCH: A separate EVM-compatible sidechain requiring a custodial bridge. The CoinFlex exchange controlled the bridge and went bankrupt in 2022, freezing user funds. This is precisely the trust problem a base-layer approach eliminates. Philosophically misaligned with Satoshi's explicit rejection of sidechain models.

---

3. Proposed Architecture

3.1 Two-Tier Hybrid Model

The platform proposes two coexisting architecture tiers sharing a common token metadata standard and universal token identifier (tokenId).

Architecture B — UI Abstraction Layer [PROPOSED — trivially implementable]

Standard BCH UTXOs. No contract locking. Token identity exists purely as wallet metadata. The wallet reads a token definition and presents BCH balances through a chosen lens. 1 BCH becomes 1,000,000 DogeCoins in the display. On-chain reality: standard BCH transaction. User experience: token economy.

This tier requires zero protocol modifications, zero new infrastructure, and is compatible with all existing BCH tooling. Enforcement is by wallet convention only — suitable for cooperative ecosystems where both parties use the platform wallet.

Architecture A — CashScript Enforcement Layer [PROPOSED — requires CashScript, live on BCH since May 2022]

BCH UTXOs locked in CashScript P2SH contracts. Contract rules enforced at consensus level. Token transfer, minting, and redemption rules are mathematically guaranteed by the BCH network itself. An OP_RETURN output carries the tokenId linking the UTXO to its metadata.

This tier provides trustless enforcement. Users need not trust the wallet software for core token mechanics — they trust BCH consensus.

Escalation path: Both tiers share the same tokenId. A soft token (Architecture B) can be upgraded to a hard token (Architecture A) by wrapping the existing BCH UTXOs in a contract transaction. The user's balance, rate, and token identity are preserved. Enforcement level is upgraded. No value change occurs.

3.2 Token Taxonomy

All tokens are defined by two parameters set immutably at genesis:

• BCH backing rate: expressed in standard satoshi tiers (1, 10, 100, 1,000, 10,000... sats per token unit). Arbitrary rates are not permitted at protocol level as they introduce rounding errors in swap calculations.
• Minting rule: open or closed.

This produces four token types:

Type	Open Mint	Protocol Swap	Example Use
Open mint utility token	Yes	Yes — automatic	Community tokens, merchant tokens
Open mint with founder fee	Yes	Yes — fee deducted	Revenue-generating utility tokens
Closed mint limited supply	No	No — third party	Project tokens, governance tokens
Closed mint stablecoin	No	No — issuer portal	USDC-BCH, USDT-BCH

Stablecoins carry an additional type flag distinguishing them from standard tokens. This prevents the wallet from applying the BCH backing rate as the exchange rate for stablecoins — their dollar peg is maintained by the issuer's fiat reserves, not by their BCH substrate.

3.3 Protocol Swap Mechanism [PROPOSED — novel]

For open mint tokens, the minting and redemption rules function simultaneously as an exchange mechanism. No counterparty, DEX, liquidity pool, AMM, or oracle is required.

The exchange rate between any two open mint tokens is derived mathematically from their genesis parameters:

Token A rate: 1 unit = 100 sats
Token B rate: 1 unit = 1,000 sats
Exchange rate: 1 Token B = 10 Token A (exact, always)

A swap transaction redeems the source token, releasing BCH satoshis, then mints the target token by sending those satoshis to the target contract. Both operations occur atomically in a single BCH transaction.

The protocol rate becomes the gravitational center. Market prices orbit around it. Deviations represent market premium or discount above the guaranteed mathematical floor.

This only applies to open mint tokens. Closed mint tokens and stablecoins require third-party exchange mechanisms for secondary market trading — the platform integrates with these via wallet UI without hosting them directly.

---

4. Economic Model

4.1 BCH Floor Value Guarantee [PROPOSED — novel]

Every token in the system — regardless of issuer status, market conditions, or secondary market price — has a mathematically guaranteed minimum recoverable value in BCH satoshis. This value is always accessible via the token's redemption function.

If an issuer disappears, becomes insolvent, or ceases operations, token holders can always redeem for the underlying BCH. This is the first token standard in any ecosystem to provide this guarantee. USDC, USDT, and all ERC-20 tokens have zero on-chain backing — if the issuer fails, recovery depends entirely on fiat reserve proceedings.

For stablecoins specifically, this creates a new spectrum of risk profiles based on the backing rate chosen at genesis:

• Low rate (100 sats per $1): symbolic BCH floor, primary backing is fiat reserves
• Medium rate (10,000 sats per $1): meaningful BCH floor, partial on-chain protection
• High rate (1,000,000 sats per $1): substantial BCH floor, significant bankruptcy protection

4.2 BCH Scarcity Amplification [DESIGN PROPERTY — not a guaranteed outcome]

Every token created requires BCH committed to a specific use case. This BCH remains redeemable at any time — it is not destroyed or permanently removed. However, while committed, it is unavailable to other market participants.

BCH has a hardcapped supply of 21 million coins. The proposed platform creates additional demand for BCH by providing utility use cases requiring BCH commitment. More platform adoption means more BCH committed to token use cases, which means less BCH available to others seeking it on open markets. This amplifies the scarcity that the protocol's supply cap already provides.

This is a design property of the architecture, not an engineered mechanism. It is stated honestly: it is a tool that empowers existing protocol scarcity, not a guarantee of specific price outcomes.

4.3 Rate Purity Principle [PROPOSED — novel]

The BCH backing rate is a unit of divisibility definition, not a market price. Once set at genesis, it is immutable. What a token trades for on secondary markets is entirely separate from and irrelevant to the protocol rate.

This means:

• A stablecoin set at 1$ = 100 sats may trade at 37,399 sats on a secondary market — the protocol rate remains 100 sats for all mint and redeem operations
• A utility token set at 1 unit = 1,000 sats may trade at 500 sats or 5,000 sats — the protocol rate remains 1,000 sats
• Protocol mechanics never follow market prices — markets may choose to anchor to protocol rates as a reference point

---

5. Token Economy Platform

5.1 Founder Fee Mechanism [PROPOSED]

Token creators may configure a percentage fee (0–5%, with genesis-defined immutable maximum cap) payable to their address on each mint and redemption. This fee is enforced by the contract in Architecture A — it cannot be bypassed.

This creates passive BCH income for token creators proportional to their token's adoption. The same contract pattern covers three use cases:

• Single founder: fee paid to one address
• Royalty distribution: fee split between multiple beneficiaries at defined percentages
• Franchise fee automation: fee split between franchisee and franchisor automatically

5.2 Membership Tokens [PROPOSED]

A contract that grants access to services based on minimum token holdings. The wallet proves membership automatically via cryptographic signature — no username or password required. Creator access to exclusive content is a specific use case of the same implementation.

5.3 Voluntary Marketing Revenue Share [PROPOSED — novel business model]

Token creators may optionally share a percentage of their founder fee revenue with the platform in exchange for promotional placement in the token discovery browser. This is never mandatory.

Participation tiers range from basic listing (zero revenue share) to flagship status (negotiated revenue share with co-marketing). The platform earns proportionally to ecosystem success. Token creators advocate for the platform because it serves their interests. The relationship is symbiotic not extractive.

5.4 Platform Revenue Model

Revenue sources in order of launch phase:

1. Zero fees at launch — maximum adoption velocity
2. Founder fees enabled — creators earn passive BCH income
3. Voluntary marketing revenue share — platform earns from successful tokens
4. Wallet swap service fee (0.5–1% on protocol swaps) — scales with volume
5. Relay infrastructure subscriptions — recurring business revenue
6. Analytics and premium tools — high margin upsell

---

6. Novel Contributions

The following contributions are identified as novel. Claims are stated precisely — novelty is assessed against publicly known existing systems as of the time of writing.

1. Protocol-as-exchange: Open mint rules combined with fixed BCH backing rates make the minting and redemption mechanism itself the exchange. No DEX, liquidity pool, AMM, or counterparty needed for open mint tokens.

2. Guaranteed on-chain floor value: Every token has a mathematically guaranteed minimum recoverable BCH value independent of issuer status. No existing token standard on any chain provides this.

3. Rate as financial instrument classifier: A single genesis parameter determines which economic category a token belongs to — from symbolic BCH floor to full overcollateralization. Same contract standard produces genuinely different financial instruments.

4. Counterparty-free swap via open minting: Any open mint token swappable with any other open mint token at mathematically exact rate without finding a willing counterparty. The contract is the counterparty.

5. Hybrid Architecture A/B: Graceful duality between on-chain enforced contracts and pure UI abstraction, sharing the same metadata standard and tokenId, with seamless escalation path between tiers.

6. BCH scarcity amplification as design property: Platform designed such that ecosystem growth mechanically amplifies BCH's existing protocol-level scarcity by creating additional demand for BCH commitment. Not a guarantee — a structural property.

7. Open mint rule as universal swap gate: A single binary parameter determines protocol swap eligibility for any token, any version, any future standard iteration. Self-governing without committee or versioning body.

8. Satoshis as mathematical unit of account: BCH satoshis function as a unit of divisibility definition at the protocol layer, completely independent of market price. No existing token system makes this architectural distinction explicitly or designs around it deliberately.

9. Voluntary marketing revenue share: Token creators optionally share fee revenue with the platform in exchange for promotional placement — platform earns proportionally to ecosystem success without mandatory extraction from founders.

10. Token floor value as bankruptcy protection layer: The BCH backing rate creates a provable, immediately recoverable on-chain asset that survives issuer bankruptcy independently of fiat reserve recovery proceedings.

---

7. BCH Protocol Alignment

The proposed ecosystem does not modify, extend, or reinvent any BCH protocol feature. It builds within the existing BCH design as a natural application layer.

BCH's native protocol properties — including SPV verification and UTXO pruning — are inherited by any project building on BCH. The proposed ecosystem benefits from these properties as a consequence of its foundation choice, not as designed features of the platform itself. By building entirely on the BCH base layer, the ecosystem inherits the protocol's scalability properties that Satoshi designed into the original system and that BCH faithfully preserves.

The platform's architecture is consistent with Satoshi's explicit statements regarding on-chain scaling, rejection of second-layer solutions as necessities, and the design of Bitcoin for microtransaction support at base layer. BCH's block size increases and competitive fee market implement this vision. The proposed token platform operates within and benefits from this design.

---

8. What This Document Is and Is Not

This document is:

• An internal reference capturing architectural design decisions
• A guide for implementation
• A record of the reasoning behind each design choice
• A starting point for a future public whitepaper

This document is not:

• A claim of working implementation
• A public whitepaper
• A guarantee of any economic outcome
• A final specification — details will be refined during implementation

Implementation begins with Architecture B. The token metadata standard and wallet interface will be built and tested before any Architecture A contract work begins. The full whitepaper will be written after implementation validates the architectural claims made here.

---

Document status: Pre-implementation concept. All [PROPOSED] claims require implementation validation before public release.