Pre-Development Structural Blueprint — Master Structural Blueprint binding on all workstreams
Master Structural Blueprint · Binding on All Workstreams
The Model — In One Paragraph
A fixed $100 participation, capped at 10,000,000 participants. Capital is committed for a five-year cycle.
275 BTC distributed to 275 winners drawn from the founding cohort of one million — one Bitcoin to each winner, selected by sealed VRF on-chain, paid at Year 5 alongside the daily-draw winners.
1 BTC per sealed slot — 1,825 daily slots total across the five-year cycle, sealed by VRF against the full 10,000,000-participant universe from Day 1. Every participant has identical odds regardless of when they joined. Any sealed slot belonging to an unfilled position is re-drawn against actual participants at Year 5 so no winning slot is wasted. All Bitcoin (the 275 founding and the 1,825 daily) is purchased at Year 5 from treasury profit above cost basis — and only if profit is sufficient to cover the full 2,100 BTC obligation at Year 5 market price. If profit is insufficient, no Bitcoin is purchased and all profit instead flows into the pro-rata cash distribution.
Founding-million participants remain eligible for the daily 1 BTC draws across all five years — the founding draw and the daily draws are independent. A founding participant can win in both.
Year 5 surplus — whatever remains after the on-chain treasury satisfies its obligations is distributed: 20% to the founder, 80% to participants pro rata.
Downside honest: outcomes depend entirely on ICP market performance across the five-year cycle. If the Participant Pool does not appreciate above cost basis, there is no profit — no Bitcoin is purchased and no founder fee is paid. Participants share the pool pro rata (which may be less than $95). The $5 Operating Fee is consumed regardless. The $100 entry is at risk. No principal return is promised.
The Bitcoin distribution mechanics are subject to Gibraltar authorisation. If the required authorisation is not obtained, the protocol does not launch.
1. System Purpose
Bitcoin Storm is a deterministic capital protocol designed for deployment on the Internet Computer Protocol (ICP).
The protocol operates under a Bitcoin-native thesis, with ICP serving as the deterministic execution and settlement layer.
The system is structured to:
Convert validated participant capital into predefined ICP exposure under encoded routing logic
Operate exclusively under rule-based, non-discretionary execution
Eliminate human override of capital routing and outcome logic
Segregate capital pools under immutable Capital Architecture constraints
Encode all allocation, distribution, surplus, and reconciliation logic prior to launch
Procedural Guarantee
The architecture guarantees procedural integrity. It does not guarantee financial outcomes.
2. Campaign Architecture
Bitcoin Storm operates as a single deterministic campaign. The system coordinates up to 10,000,000 participants, each contributing $100, creating a $1,000,000,000 capital base.
Upon intake, capital is permanently segregated into two fixed capital pools.
Pool
Allocation
Function
Participant Pool
$950M
Direct ICP token purchase (liquid long position)
Operating Fee Reserve
$50M
Compliance, audit, infrastructure and system integrity
Structural Restrictions
No optimisation layer
No discretionary trading
No derivatives
No leverage
No inter-pool capital transfer except under predefined terminal reconciliation logic
Segregation is immediate and irreversible.
3. Capital Flow Overview
Entry Sequence
Validated Participant Capital
↓
Identity Verification Layer
↓
Whitelist Enforcement
↓
Deterministic Conversion Engine
↓
Segregated Capital Architecture Pool Allocation
At no stage may capital be manually redirected, intercepted, or reassigned outside encoded logic.
4. Core Invariants
The following constraints must be enforceable at the protocol level:
Non-Negotiable Structural Constraints
No human discretionary override of capital routing
No reallocation between pools after segregation
No leverage
No derivatives
No active discretionary trading
No post-deployment modification of economic distribution rules
No capital access outside encoded withdrawal conditions
Operating Fee Reserve fixed at $50M
Deterministic execution only
All routing and allocation logic auditable on-chain
Violation of any invariant constitutes structural failure.
5. Determinism Model
All economic logic must be predefined prior to launch, publicly inspectable, mathematically constrained, and executed via ICP-native on-chain logic.
If randomness is incorporated, it must be verifiable, cryptographically provable, non-manipulable, and independent of operator input.
Randomness Implementation — VRF
Where randomness is required — specifically for the daily 1 BTC allocation draw and the 275 BTC sealed founding draw — the protocol uses a Verifiable Random Function (VRF) pre-generation approach. A long deterministic reward allocation sequence is generated at initialisation. Each daily cycle reads the next entries from this sealed reward ledger, maintaining verifiable randomness while eliminating daily computation overhead across the five-year lifecycle.
6. Settlement Logic
The Year 5 settlement sequence must be defined before deployment.
Settlement trigger encoded at launch (Year 5 protocol close)
No early exit, refund, or redemption mechanism
Year 5 distribution executed deterministically at settlement: Pool valuation, profit calculation (Pool Value − Cost Basis), conditional BTC purchase, 80/20 residual split
80% / 20% distribution split applied automatically
Charitable earmark applied at distribution: 10% of each participant's cash share locked in their Storm wallet for participant-directed charitable routing (12-month direction window; auto-distribution to top three nominated charities thereafter). Earmark applies in every distribution scenario; bitcoin won via founding or daily draws is delivered outright. Mechanics documented in the Storm Community Fund
No discretionary case-by-case processing
The Year 5 settlement cannot depend on managerial judgement. All distribution logic is fixed in canister code before launch.
7. Governance Scope
Governance authority is deliberately limited.
Governance May Control
Non-economic UI configuration
Communication updates
Bug patch upgrades within defined constraints
Governance May Not Control
Capital routing
Pool allocations
Distribution ratios (80% / 20%)
Settlement mechanics
Operating Fee Reserve percentage (5%)
Economic rule modifications
Economic logic remains fixed post-deployment.
8. No Token at Launch
The Bitcoin Storm protocol does not issue a project token, ecosystem token, or utility token at launch. There is no Initial Coin Offering, no token sale, no airdrop, and no listing. Participation is by a fixed $100 token-swap entry of a whitelisted on-chain asset directly into the protocol treasury; participants receive a non-transferable Engine slot, not a tradable token.
The Bitcoin Storm operating entity reserves the right to consider issuing a token after the Year 5 settlement event. Any such future token would be the subject of a separate architectural specification at that time and is not part of the structure addressed in this document.
No Token at Launch
The deterministic capital architecture stands alone. There is no second instrument layered on top of the protocol, and no token-based mechanism interacts with capital routing, pool allocation, surplus, or distribution logic.
9. Upgrade & Immutability Framework
Prior to Deployment
Upgrade pathway must be explicitly defined
Governance permissions must be bounded and documented
Lock conditions must be publicly disclosed
After Deployment
Core economic logic is locked
Pool allocation logic is immutable
Surplus hierarchy rules cannot be altered
Deterministic routing rules cannot be modified
No structural economic modification may occur after launch.
10. Off-Chain Dependency Policy
Core system functions must remain ICP-native: capital routing, pool segregation, deterministic allocation, draw execution, distribution mechanics, settlement sequence execution.
Permitted Off-Chain
User interface hosting
Analytics dashboards
Informational reporting layers
Off-Chain May Not Influence
Capital control
Routing pathways
Outcome logic
Draw eligibility
Settlement distribution sequencing
Economic determinism must remain entirely on-chain.
11. Compliance Alignment Principles
The architecture is structured to avoid characteristics of discretionary capital management, minimise collective investment scheme exposure, avoid reliance on managerial effort, avoid promissory financial representations, avoid yield guarantees, and ensure transparency of encoded process.
Regulatory Status
This document forms the structural basis for regulatory review and compliance validation.
Cross-Reference — Compliance Suite
The following compliance documents have been prepared in alignment with this architectural framework and must be read alongside it:
Howey Test Defence — demonstrates why protocol participation does not constitute an investment contract; no token issued at launch
MiCA Compliance Positioning — establishes the protocol's position outside MiCA token regimes (no token issued) and outside CASP/financial-instrument classifications
Not a Fund — demonstrates the protocol falls outside CIS, AIFMD, and Investment Company Act definitions
Risk Register — comprehensive regulatory risk assessment with AML/VASP framework
Protocol-First Development Strategy — rationale for the build sequence and its compliance implications
12. End-State Resolution (Full Campaign)
At lifecycle completion:
Pools reconcile via predefined equalisation logic
Surplus distributed according to encoded priority order
Performance Fee executed strictly according to predetermined rule
Remaining capital distributed per deterministic allocation model
System transitions to terminal state
No further capital intake permitted after closure.
13. Founding Million — 275 BTC Sealed Draw (Addendum)
Founding Million Incentive Mechanism
The Founding Million draw is a structural incentive mechanism reserved exclusively for the first 1,000,000 participants. At the moment the 1,000,000th participant is confirmed, an on-chain VRF executes and selects 275 winning wallets from the founding million pool. Results are cryptographically sealed and remain invisible until Year 5 settlement — at which point, if treasury profit is sufficient to purchase the full 2,100 BTC obligation at market price, all 275 winners are announced alongside the 1,825 daily winners and each credited with 1 BTC.
Encoded & Immutable Post-Launch
The BTC threshold rule (profit must cover 2,100 BTC at Year 5 market price) cannot be modified post-launch
The 275 BTC allocation is fixed
The 1 BTC per winner rule is immutable
The simultaneous announcement and credit mechanics cannot be altered
Once the VRF executes at the 1,000,000th participant, the sealed result is immutable
Document Status
Master Structural Blueprint
This document defines the non-negotiable structural framework of Bitcoin Storm. It takes precedence over all other specifications, plans, and descriptions where conflict arises.
All technical specifications, whitepapers, smart contract builds, operational models, and compliance documentation must conform to these architectural boundaries. Any deviation requires formal architectural revision prior to implementation.