Skip to content
BitcoinAI — The AI Blockchain for Bitcoin
GitHub (opens in a new tab)White Paper
BitcoinAI — The AI Blockchain for Bitcoin

Tokenomics

Migration

The migration lifecycle, reserve model and safeguards separated from the core tokenomics overview.

Pre-mainnet access

A temporary Ethereum representation can bridge project funding to native BTCAI.

Planned
  1. 01Approved BTCAI-ETH Issuance
  2. 02Native BTCAI Migration Reserve
  3. 03Mainnet Launch
  4. 04Migration Window
  5. 05BTCAI-ETH Burn / Lock
  6. 06Native BTCAI Released
BTCAI-ETH is a planned ERC-20 representation intended for pre-mainnet project funding/community distribution and later migration to native BTCAI, subject to legal review, final issuance terms, reserve accounting, and published migration rules.

BTCAI-ETH is not

  • A guaranteed presale
  • A guaranteed investment
  • A guaranteed listing
  • Risk-free
  • Classified as a security or non-security without counsel

No unbacked migration claims

Every migration token should have transparent native BTCAI reserve accounting.

Planned
For each legitimate migration-eligible BTCAI-ETH there should be one reserved native BTCAI under published accounting rules.

1 BTCAI-ETH

ERC-20 on Ethereum

1 reserved native BTCAI

Held in a published migration reserve

This does not mean native BTCAI is transferable before mainnet.

For each legitimate migration-eligible BTCAI-ETH there should be one reserved native BTCAI under published accounting rules.

Issued BTCAI-ETH
Total ERC-20 supply created under approved terms
Launch parameter / not yet live
Migration-eligible BTCAI-ETH
Issued tokens that meet published eligibility rules
Launch parameter / not yet live
Reserved native BTCAI
Native BTCAI set aside 1:1 against eligible BTCAI-ETH
Launch parameter / not yet live
Migrated amount
Native BTCAI released against consumed claims
Launch parameter / not yet live
Burned / locked BTCAI-ETH
ERC-20 permanently removed from circulation
Launch parameter / not yet live
Remaining reserve
Reserved minus migrated; must never go negative
Launch parameter / not yet live

Architecture only — no reserve exists yet, so no figures are shown.

From ERC-20 to native

Migration should be one-way, auditable, and resistant to double claims.

Planned
Planned migration architecture
  1. 1Eligibility snapshot / validationEligible balances are fixed and published before the window opens.
  2. 2Wallet connects to the official migration appOnly the app linked from bitcoinai.network is official.
  3. 3User submits BTCAI-ETHThe holder chooses the amount and the native destination address.
  4. 4Contract burns or permanently locks BTCAI-ETHThe ERC-20 can never be redeemed again.
  5. 5Migration proof is generatedThe source transaction becomes a verifiable claim.
  6. 6BitcoinAI verifies the claimAfter the required Ethereum confirmation depth.
  7. 7Reserved native BTCAI is releasedFrom the published migration reserve, 1:1.
  8. 8Claim is marked consumedRecorded in the consumed-claim registry.
  9. 9Explorer / reserve state updatesPublic reserve accounting reflects the migration.

No migration app, contract or claim flow exists yet. This describes the planned architecture only.

Network economics ultimately connect to people and organizations operating real digital systems.Photo by Vitaly Gariev · Unsplash

One claim, one release

A migration token must not be redeemable twice.

  • Burn or permanent lock
  • Unique claim ID
  • Source-chain transaction hash
  • Migration nonce
  • Consumed-claim registry
  • Chain ID binding
  • Reserve accounting
  • Proof confirmation depth
  • Migration contract audit
  • Pause mechanism
  • Emergency recovery policy
Claim commitmentConceptual
migrationClaimId =
Hash(
  sourceChain
  || sourceTx
  || sourceWallet
  || amount
  || destinationWallet
  || nonce
)

Any change to any input produces a different ID, and each ID can be consumed exactly once.

Network economics should be understandable as operating rules and planning inputs—not as speculative promises.Photo by Vitaly Gariev · Unsplash