Bitcoin-aligned work + sovereign AI execution

Bitcoin Security. AI Intelligence. Multichain Scale.

BitcoinAI is a sovereign Cosmos-derived Layer 1 designed to connect Bitcoin-aligned work with Delegated Proof of Stake, verifiable AI activity, smart contracts, appchains, and multichain settlement.

Bitcoin remains the proof-of-work and value anchor. BitcoinAI adds the execution, coordination, and verification layers needed for the AI economy.

Explore the Architecture Read the White Paper

View AIPoW

Two engines, one network: AIPoW + DPoS
Bitcoin-compatible AuxPoW: Merge Mining
Verifiable AI receipts: Proof-of-AI
Smart contracts + appchains: Contracts

System overview

A sovereign blockchain with five connected layers.

Bitcoin provides work. AIPoW qualifies work. DPoS finalizes state. BatteryAGI executes AI. BitcoinAI coordinates and settles the result.

See the Full Ecosystem

LAYER 5
Multichain / Appchain Layer
- IBC
- Appchains
- EVM-connected ecosystems
- Solana-connected ecosystems
- Future external networks
AI Execution Layer executes AI
LAYER 4
AI Execution Layer
- BatteryAGI orchestration
- Model routing
- Fusion AI
- Off-chain compute
- AI receipts
BitcoinAI Layer 1 finalizes state
LAYER 3
BitcoinAI Layer 1
- Delegated Proof of Stake
- CometBFT finality
- Smart contracts
- Governance
- Settlement
- Protocol state
AIPoW qualifies work
LAYER 2
AIPoW
- AuxPoW verification
- Work submission
- AI-enhanced work option
- Reward accounting
- Bitcoin-style halving envelope
Bitcoin Foundation provides work
LAYER 1
Bitcoin Foundation
- Bitcoin SHA-256 work
- Parent chain headers
- Shared work / merge-mining source
- Value anchor

Hybrid merge architecture

Bitcoin-aligned work on one side. Sovereign Cosmos execution on the other.

Hybrid Merge Bitcoin Protocol to Cosmos

The phrase describes BitcoinAI's architecture: Bitcoin-compatible merge-mined work feeds the AIPoW work layer, while a sovereign Cosmos SDK / CometBFT blockchain provides consensus, state, smart contracts, governance, and multichain coordination.

Engine A

Bitcoin / AIPoW

Work
Merge mining
Issuance
AI-qualified weighting

Engine B

BitcoinAI / DPoS

Finality
Transaction ordering
State
Smart contracts
Governance

One BitcoinAI Network

Bitcoin consensus and Cosmos consensus are not literally merged. BitcoinAI verifies Bitcoin-aligned work while maintaining its own sovereign validator set, chain ID, state machine, governance, and upgrade path.

Bitcoin-aware infrastructure

BitcoinAI understands Bitcoin work without asking Bitcoin to change.

1Bitcoin Header
2Bitcoin Light-Client State
3Chainwork / Canonical Tip
4AuxPoW / Merge-Mining Proof
5BitcoinAI Verification

Planned light-client functions

Engineering

Track Bitcoin headers
Track cumulative chainwork
Determine the canonical tip
Handle reorganizations
Apply confirmation-depth policies
Validate merge-mining proofs
Distinguish Bitcoin shares from canonical Bitcoin blocks where the implementation supports it

Exact Bitcoin light-client and AuxPoW rules remain implementation parameters until final testnet and mainnet specifications are published.

Why this matters

Bitcoin-aligned work
No Bitcoin consensus change
Shared mining infrastructure
Higher-assurance anchoring possibilities
Bitcoin-aware application design

Work-based issuance

AIPoW combines Bitcoin-aligned work with verifiable AI contribution.

AIPoW is the BitcoinAI protocol name. AuxPoW is the underlying merge-mining mechanism used for Bitcoin-compatible shared work.

Canonical

Standard path

Bitcoin-aligned work
AIPoW validation
1.00reward weight

AI-enhanced path

Bitcoin-aligned work
+ valid Proof-of-AI receipt
AIPoW validation
1.05reward weight

E: fixed epoch distribution budget
wᵢ: participant's accepted work weight
Σw: sum of all accepted work weights in the epoch

The 1.05 weight does not mint an extra 5% outside the reward budget. It changes how a fixed epoch budget is divided among qualifying work.

Scarcity by design

Bitcoin-style halvings define the envelope. BitcoinAI distributes only the active portion.

Issuance envelope: Bitcoin-style halvingCanonical
Theoretical envelope: 105,000,000 BTCAI AIPoW authorizationCanonical
Active distribution factor: 20%Canonical
Work providers / miners: 40%Canonical
Validators / delegators: 60%Canonical

Active emissions by eraActiveTheoretical envelope

Relative shape only — not an issuance schedule.

Illustrative epoch

Illustrative

25 BTCAI

active distribution in one epoch

10 BTCAIwork providers / miners15 BTCAIvalidators / delegators

Undistributed theoretical envelope is not automatically minted or circulating.

Rewards are denominated in BTCAI, not fiat. No value is implied or guaranteed.

Finality + security

AIPoW provides work. Delegated Proof of Stake secures and finalizes the chain.

Validators propose and vote on BitcoinAI blocks.
CometBFT-style BFT finality: once committed, a block is final.
Delegators can participate without running infrastructure.
Slashing and unbonding enforce validator behavior.
AIPoW work does not independently determine BitcoinAI application history.

01AIPoW Claim
02Validator Verification
03PoS Consensus
04Final BitcoinAI State

Reward weight: Linear; No super-linear yield boost.
Effective cap: 10,000,000; BTCAI reward and voting weight per validator.; Canonical
Unbonding: 21 days; Target unbonding period.; Proposed
Commission: Per validator; Set by each validator; shown to delegators.

Explore Validators

Two engines. One network.

Work determines contribution. Stake secures finality.

AIPoW

Purpose

Work-based issuance
Bitcoin merge mining
Useful AI enhancement
Permissionless work contribution

DPoS

Purpose

Canonical consensus
Finality
Smart-contract state
Governance
Settlement

“AIPoW does not replace consensus. DPoS does not replace work. BitcoinAI uses each mechanism for the role it performs best.”

Verifiable AI activity

A hash proves integrity. A receipt proves more.

Engineering

A hash can prove

Content commitment
Integrity
Reference to an output

A hash alone does not prove

That the claimed model ran
That computation actually occurred
That a provider performed the task
That the job was not replayed

That is why BitcoinAI uses richer Proof-of-AI receipts, organised as a verification ladder:

Tier 0Hash CommitmentProvenance / integrity only · No premium qualification by itself
Tier 1Signed Provider ReceiptProvider identity · Model identifier · Request/output commitment · Signature
Tier 2Independent VerificationExternal verifier confirms policy/result
Tier 3TEE AttestationTrusted execution evidenceOptional / future
Tier 4zkML / Verifiable InferenceCryptographic proof where practicalOptional / future

Tiers 3–4: Optional / future-capable depending on implementation and cost.

AI receipts

Compact evidence on-chain. Heavy AI data off-chain.

Engineering

ProofOfAIReceiptschema · conceptual

Proof-of-AI receipt fields
Field	Type	Description
job_id	bytes32	Unique job identifier
requester	address	Account that requested the job
provider_id	address	AI provider identity
model_id	string	Model identifier
model_hash	bytes32	Model version or artifact hash
input_hash	bytes32	Commitment to the request input
output_hash	bytes32	Commitment to the result
exec_meta_hash	bytes32	Execution metadata commitment

Developer view: 7 more fields

Additional receipt fields
nonce	uint64	Anti-replay nonce
verification	enum	Verification method / tier
provider_sig	bytes	Provider signature
verifier_evidence	bytes32?	Independent verifier evidence
tee_attestation	bytes32?	TEE attestation hash
zk_proof	bytes32?	zk proof hash
payment_ref	bytes32	Settlement / payment reference

Anti-replay binding

Hash(chain_id || epoch || miner_address || auxpow_work_id || model_hash || input_hash || output_hash || job_nonce)

Conceptual binding structure; final encoding is implementation-defined.

Merkle batching

1. Many receipts2. One Merkle root3. Compact on-chain commitment4. Individual inclusion proofs

AI off-chain. Trust on-chain.

BitcoinAI coordinates AI without making every validator run the model.

Request on BitcoinAI. Execute on BatteryAGI. Verify on BitcoinAI. Settle in BATT.

01BitcoinAIRequest created
02BatteryAGIQuote returned
03BitcoinAIBTCAI escrowed
04BatteryAGIJob routed
05Off-chainBatteryAGI executes
06Off-chainResult produced
07BatteryAGI → BitcoinAIProof-of-AI receipt returned
08BitcoinAIBitcoinAI verifies
09BitcoinAISettlement released
10BATTBATT providers paid

Stays off-chain

Prompts
Model weights
Images / video
Embeddings
Tensors
Logs
Large model outputs

Recorded on BitcoinAI

State
Commitments
Receipts
Settlement
Verification
Smart-contract consequences

Explore AI

Programmable BitcoinAI

Smart contracts turn verified AI activity into applications.

Planned

Security-critical protocol functions should remain native audited modules where appropriate. Smart contracts extend application logic without replacing the core protocol.

EVM runtimeEVM-compatible smart-contract executionPlanned

CosmWasm / WASMWebAssembly smart contracts (CosmWasm)Planned

Build on BitcoinAI

AI-agent escrow
Marketplaces
Tokenized assets
DeFi
Automated settlement
Governance applications
NFT / digital asset logic
Application-specific workflows

Appchain-ready

Purpose-built chains can connect to BitcoinAI's AI and settlement layers.

Planned

Custom application chain
Specialized execution
Independent application logic
Connection to BitcoinAI proofs, AI services and settlement

1Appchain
2IBC / Adapter
3BitcoinAI
4BatteryAGI
5Verified Result / Settlement

Gaming appchain
AI marketplace
Institutional asset appchain
Supply-chain network
Media / content network
Agent economy

Security inheritance depends on the chosen appchain and interoperability architecture.

Multichain by design

AI requests can originate anywhere and settle through BitcoinAI.

1Source Chain
2Cross-Chain AI Request
3BitcoinAI
4BatteryAGI / BATT
5Proof / Verification
6Result Callback

Target ecosystems (conceptual)

Bitcoin-connected appsPlanned
Cosmos / IBCPlanned
Ethereum / EVMPlanned
BasePlanned
ArbitrumPlanned
OptimismPlanned
BNB ChainPlanned
PolygonPlanned
SolanaResearch target
Future chainsResearch target

No external chain is integrated today.

Design principle

Cross-chain AI jobs are asynchronous state machines, not fake atomic transactions across unrelated consensus systems.

Each route carries its own security model; see Security Boundaries below.

Scaling for AI

Scale execution by separating consensus, parallel processing, proof batching, and AI compute.

1 · Transaction lanes

Consensus critical
AIPoW
AI requests
AI receipts
Settlement
Cross-chain
General transactions

2 · Parallel execution

BlockSTM-style deterministic parallelism
Application-aware scheduling
Low-contention state design

3 · State partition keys

job ID
provider ID
model ID
chain ID
settlement ID
receipt batch ID

4 · Merkle batching

Compress many AI events into compact commitments.

5 · Off-chain compute

BatteryAGI · Provider network · Horizontal scaling

100,000–500,000

concurrent AI transactions/jobs

Research target

100K+ native TPS is a research/engineering target and must not be presented as achieved until reproducible multi-validator benchmarks exist.

Defense in depth

Separate responsibilities. Contain failures. Verify everything.

No system is absolutely secure. BitcoinAI's design aims to limit the blast radius of any single failure.

Bitcoin Work Layer

Risks

Pool concentration
Invalid AuxPoW
Stale work
Chain reorg assumptions

Mitigations

Verification
Chainwork tracking
Confirmations
Policy thresholds

PoS Layer

Risks

Validator concentration
Downtime
Equivocation
Governance capture

Mitigations

Delegation spread
Stake cap
Slashing
Governance thresholds

AI Layer

Risks

Fake receipts
Replay
Provider fraud
Unverifiable proprietary models

Mitigations

Signed receipts
Nonces
Commitments
Verifier tiers
TEE / zk options

Cross-Chain Layer

Risks

Bridge failure
Adapter compromise
Message reordering
Destination-chain finality

Mitigations

Route-specific security
Timeouts
Acknowledgements
Asynchronous state machines

What is final vs. what is still being engineered

Clear status. No hidden assumptions.

CanonicalPart of the current canonical protocol design. Not yet live; may change before mainnet through the published specification process.
ProposedA proposed design parameter subject to review, governance and change.
PlannedPart of the current design and roadmap. Not yet launched.
EngineeringBeing specified and engineered. Exact parameters and rules are not final.
Research targetAn engineering or research goal. Not a demonstrated production benchmark; subject to independent validation.

BitcoinAI protocol component status
Component	Status	Current design	Finalization needed
Sovereign Cosmos-derived Layer 1	Canonical	Cosmos SDK / CometBFT sovereign L1	Mainnet genesis parameters
AIPoW	Canonical	AuxPoW-verified work with halving envelope	Epoch length and envelope parameters
Delegated Proof of Stake	Canonical	Validator + delegator security, BFT finality	Active set size, slashing parameters
210,000,000 max supply	Canonical	Fixed ceiling, 105M / 105M split	Genesis distribution details
1.00 / 1.05 work weights	Canonical	Relative weights within a fixed budget	Proof-of-AI qualification rules
20% active distribution	Canonical	Share of halving envelope actively distributed	Governance change process
40% / 60% active split	Canonical	Work providers / validators + delegators	—
10,000,000 validator cap	Canonical	Linear effective stake up to cap	Enforcement module specification
Bitcoin light client	Engineering	Header tracking, chainwork, canonical tip, reorg handling, confirmation depth	Confirmation depth and reorg policy
AuxPoW implementation details	Engineering	Merge-mining proof format, share vs. block handling, pool integration	Final proof format and pool integration
Proof-of-AI receipt standard	Engineering	Signed receipts, anti-replay binding, verifier tiers, Merkle batching	Encoding, verifier set, tier policy
EVM runtime	Planned	EVM-compatible smart-contract execution	Runtime selection and audit
CosmWasm / WASM	Planned	WebAssembly smart contracts (CosmWasm)	Scope decision
Appchain integrations	Planned	Appchain connection to proofs, AI services and settlement	Launch partners and security model
IBC routes	Planned	IBC channels to Cosmos-ecosystem chains	Channel selection
EVM adapters	Planned	Adapters for Ethereum and EVM L2 ecosystems	Adapter security review
Solana adapters	Research target	Adapters for Solana-connected applications	Feasibility research
Native benchmark configuration	Engineering	Reproducible multi-validator throughput benchmarks	Published, reproducible results
Cross-chain security policies	Engineering	Per-route security models, timeouts, acknowledgements	Per-route policies
Oracle / pricing system	Engineering	Price and quote inputs for AI jobs and settlement	Oracle design and sources
BATT settlement reserve	Engineering	BATT settlement reserve mechanics	Reserve mechanics specification

Sovereign Cosmos-derived Layer 1Canonical
Current design
Cosmos SDK / CometBFT sovereign L1
Finalization needed:
Mainnet genesis parameters
AIPoWCanonical
Current design
AuxPoW-verified work with halving envelope
Finalization needed:
Epoch length and envelope parameters
Delegated Proof of StakeCanonical
Current design
Validator + delegator security, BFT finality
Finalization needed:
Active set size, slashing parameters
210,000,000 max supplyCanonical
Current design
Fixed ceiling, 105M / 105M split
Finalization needed:
Genesis distribution details
1.00 / 1.05 work weightsCanonical
Current design
Relative weights within a fixed budget
Finalization needed:
Proof-of-AI qualification rules
20% active distributionCanonical
Current design
Share of halving envelope actively distributed
Finalization needed:
Governance change process
40% / 60% active splitCanonical
Current design
Work providers / validators + delegators
Finalization needed:
—
10,000,000 validator capCanonical
Current design
Linear effective stake up to cap
Finalization needed:
Enforcement module specification
Bitcoin light clientEngineering
Current design
Header tracking, chainwork, canonical tip, reorg handling, confirmation depth
Finalization needed:
Confirmation depth and reorg policy
AuxPoW implementation detailsEngineering
Current design
Merge-mining proof format, share vs. block handling, pool integration
Finalization needed:
Final proof format and pool integration
Proof-of-AI receipt standardEngineering
Current design
Signed receipts, anti-replay binding, verifier tiers, Merkle batching
Finalization needed:
Encoding, verifier set, tier policy
EVM runtimePlanned
Current design
EVM-compatible smart-contract execution
Finalization needed:
Runtime selection and audit
CosmWasm / WASMPlanned
Current design
WebAssembly smart contracts (CosmWasm)
Finalization needed:
Scope decision
Appchain integrationsPlanned
Current design
Appchain connection to proofs, AI services and settlement
Finalization needed:
Launch partners and security model
IBC routesPlanned
Current design
IBC channels to Cosmos-ecosystem chains
Finalization needed:
Channel selection
EVM adaptersPlanned
Current design
Adapters for Ethereum and EVM L2 ecosystems
Finalization needed:
Adapter security review
Solana adaptersResearch target
Current design
Adapters for Solana-connected applications
Finalization needed:
Feasibility research
Native benchmark configurationEngineering
Current design
Reproducible multi-validator throughput benchmarks
Finalization needed:
Published, reproducible results
Cross-chain security policiesEngineering
Current design
Per-route security models, timeouts, acknowledgements
Finalization needed:
Per-route policies
Oracle / pricing systemEngineering
Current design
Price and quote inputs for AI jobs and settlement
Finalization needed:
Oracle design and sources
BATT settlement reserveEngineering
Current design
BATT settlement reserve mechanics
Finalization needed:
Reserve mechanics specification