Separate execution, privacy and economic security.
The protocol does not treat privacy as a visual feature or claim that ordinary EVM state is hidden. Transparent contracts remain transparent. Private value transfer occurs only inside a dedicated shielded state machine whose proofs are verified by the network.
Compatibility first
Retain Solidity, Ethereum JSON-RPC and standard wallet interfaces for the public execution path.
Privacy by explicit action
Users shield, transfer and unshield BTC through explicit operations. Privacy is never implied by default.
No new privacy coin
The privacy layer adopts Zcash-originated cryptographic concepts as technical foundations, while requiring and issuing no ZEC.
One consensus layer, two execution domains.
Deterministic execution from intent to Bitcoin commitment.
Prove validity without publishing the private transaction graph.
The privacy layer is designed around an Orchard-style note model and Halo 2 proving system concepts. It is not a fork of Zcash consensus. Circuit, curve and proof-aggregation choices are being finalized through implementation and security review.
Public BTC value enters the pool and creates an encrypted note commitment.
The sender proves ownership, balance conservation and non-double-spend without revealing the note.
A valid proof destroys the private note and releases value to a public address.
Commits to a note without exposing its owner or value.
A unique spend marker that prevents double-spending without identifying the consumed note.
Allows holder-controlled disclosure for accounting, audit or regulated counterparties.
Accepts only state transitions that satisfy the circuit's conservation and authorization rules.
A shielded transaction is accepted only when every invariant holds.
01 note_root ∈ accepted_roots
02 nullifier ∉ spent_nullifier_set
03 Verify(proof, public_inputs) = true
04 Σ inputs = Σ outputs + public_delta + fee
05 new_root = Append(old_root, commitments)
06 reserve_locked ≥ shielded_supply + public_supply
The chain publishes commitments, nullifiers, proof inputs and the resulting state root. Note plaintexts, recipient keys and private values remain outside public state.
Bitmap qualifies participation; BTC secures accountability.
Bitmap serves as a non-fungible eligibility credential, not as the chain's gas token. A candidate must prove control of valid Bitmap inscriptions and lock a BTC-denominated security bond. Slashing applies to the bond, while eligibility can be suspended or revoked by protocol rules.
Order valid state transitions
Build blocks from transactions that pass EVM execution, proof verification and reserve checks.
Sign one canonical state
Attest to the EVM state root, shielded commitment root, nullifier root and reserve accounting root.
Remain economically accountable
Double-signing, invalid-state attestation and prolonged unavailability trigger bond penalties and eligibility review.
Launch parameters remain subject to final simulation, adversarial analysis, security review and governance activation.
Three assets. Three non-overlapping jobs.
The network does not issue a new gas token. Bitmap controls scarce validator eligibility; BTCB is the launch gas asset; BTC-denominated reserves and supported adapters connect the network to Bitcoin liquidity. Separating these roles prevents governance rights, execution fees and reserve backing from being hidden inside one speculative token.
Validator eligibility
2,100 valid Bitmap are locked per candidate. The same Bitmap cannot qualify two concurrent validator seats.
SCARCE ACCESSGas and fee accounting
Execution fees are denominated in BTCB at launch, preserving a Bitcoin-denominated economy without creating new monetary issuance.
EXECUTION UNITLiquidity and settlement
Supported Bitcoin assets enter through explicit adapters with separate reserve accounting, risk limits and redemption paths.
CAPITAL LAYERAt the launch configuration, a fully occupied validator set requires 44,100 concurrently locked Bitmap, assuming one non-reusable eligibility set per validator. This is protocol demand, not a price forecast.
No fixed APY. Revenue follows real network usage.
Gross validator revenue=gas share + priority fees + permitted MEVNet validator revenue=gross revenue − infrastructure − settlement − penaltiesBitmap capital efficiency=net validator revenue ÷ locked Bitmap market valueAcquisition is funded only from realized foundation-validator net revenue. It is not financed by token inflation and does not guarantee market price or liquidity.
Deploy EVM applications normally. Add privacy only where required.
Public applications retain familiar Ethereum tooling. Privacy-aware applications add a wallet-side proving flow and call dedicated shielded-pool interfaces. Ordinary Solidity storage is never represented as private.
Standard EVM
Solidity contracts, ERC standards, existing wallets and standard JSON-RPC methods.
eth_call · eth_sendRawTransaction · eth_getLogsPrivate settlement
Wallet constructs notes and proofs locally, then submits public inputs to the shielded verifier.
shield · transfer · unshield · discloseProof-aware contracts
Contracts consume verified claims—such as balance sufficiency or membership—without receiving private note data.
verifyProof(publicInputs, proof)Operational authority must be visible, bounded and reversible.
MEV remains observable
Public transactions may still face ordering, arbitrage and liquidation competition. The protocol does not market ordinary mempool activity as private.
Payload confidentiality
Encrypted note payloads reduce content leakage, while timing and entry/exit correlation remain explicit metadata risks.
No hidden MEV subsidy
Any permitted proposer revenue is included in validator unit economics and must be measurable rather than presented as risk-free yield.
Privacy does not remove trust assumptions.
BTC custody and redemption
Any bridged representation of BTC depends on a custody, federation or cryptographic bridge design. Reserve accounting and failure recovery must be independently verifiable.
Soundness and implementation
A circuit flaw can permit unauthorized value creation or loss of privacy. Specifications, test vectors and multiple independent audits are mandatory before mainnet.
Timing and network analysis
Zero-knowledge proofs do not automatically hide IP addresses, timing, deposit/withdrawal correlation or wallet behavior. Network-layer protections require separate design.
Validator concentration
A small active set improves coordination but increases censorship and liveness risk. Rotation, delegation limits and emergency governance require formal analysis.
The numbers investors and projects should monitor.
A credible launch requires public telemetry that separates adoption, security, reserves and economics. The network dashboard is designed around auditable protocol data rather than promotional transaction counts.
Total and per-validator eligibility inventory; concurrent reuse must equal zero.
Seat ownership, foundation share, delegation concentration and correlated infrastructure.
Verified reserves divided by public plus shielded BTC-denominated liabilities.
Active notes, commitment-tree growth and concentration of shield/unshield timing.
BTCB gas paid by users, excluding internal transfers, incentives and wash activity.
Time between Bitcoin commitment transactions, confirmation depth and fees paid to miners.
Invalid proofs, client version mismatches and circuit-verifier rejection categories.
Pending deposits, withdrawal latency, rate-limit utilization and reserve reconciliation.
Five questions that cannot be answered by price.
- Is Bitmap demand created by mandatory, non-reusable validator locks—or only by marketing?
- Does real user fee revenue exceed validator and Bitcoin-settlement operating cost?
- Are BTC-denominated liabilities continuously covered by independently verifiable reserves?
- Can governance pause risk without silently changing balances or confiscating private notes?
- Can projects migrate using standard EVM tooling without surrendering user privacy keys?
Mainnet preparation is underway.
State transitions, proof statements, validator eligibility and bridge invariants are entering final review.
FINAL REVIEWShield, transfer, unshield and proof-verification components are being integrated into the pre-mainnet stack.
INTEGRATIONTest vectors, threat-model review and independent audit sequence are prepared for validation.
SCHEDULEDActivation follows completion of security validation, economic calibration and governance readiness.
PREPARINGBitmap Privacy Chain is in launch preparation and is not yet active on mainnet. The architecture shown here defines the intended launch system; final parameters remain subject to security validation before activation.