Global Economic Invariants
Non-negotiable protocol constraints. Any violation constitutes a system failure.
- 01The Operating Fee Reserve ($5 per participant entry, $50M at full subscription) funds five-year protocol operations only. It does not fund BTC prizes. BTC is purchased exclusively from Participant Pool profit above cost basis. Neither the Operating Fee Reserve nor any portion of it is a transfer of participant capital.
- 02Participant capital and the Performance Fee are economically segregated from inception. Segregation applies from the first swap and persists throughout the full lifecycle.
- 03Under no circumstances may ICP attributable to the Performance Fee be sold, liquidated, transferred, or otherwise realised unless an explicit Performance Fee Realisation Event is triggered under a separately defined governance specification.
- 04Participant-attributable ICP may be sold, unwound, or distributed independently without triggering any sale or realisation of the Performance Fee.
- 05The Performance Fee must remain inaccessible, non-withdrawable, and non-distributable during system operation.
- 06Year 5 surplus distribution executes after all on-chain obligations are settled. The 80/20 split (80% to participants, 20% to founder) cannot be modified after deployment.
- 07No system module may override deterministic payout sequencing: BTC Allocation → Year 5 Settlement → 80/20 Surplus Distribution.
- 08No permanent static BTC treasury wallet may exist. Long-term cumulative BTC exposure must not rely on a single harvestable key structure.
- 09BTC allocation randomness must be cryptographically committed, time-sealed, and forward-linked across epochs. No administrator may alter, reseed, or override allocation outcomes.
- 10All allocation and Year 5 settlement mechanisms must remain on-chain verifiable, auditable, and immune to discretionary modification.
- 11Participant registration is closed at the end of Month 48 (twelve months before Year 5 settlement). The capital-formation entry function must reject any registration attempt past Month 48 + 0 seconds, regardless of remaining capacity below the 10,000,000 cap. This ensures every participant has at least twelve months of locked-capital exposure before settlement. The founding-cohort window (slots 1 through 1,000,000) closes independently when the millionth slot is filled — that closure does not affect general registration up to Month 48.
Capital Formation + Capital Architecture
1B campaign capital input, pool allocation, and Year 5 settlement rules.
Capital Input
entry_price $100 // fixed — no variable pricing
total_capital $1,000,000,000 // 1B campaign target
accepted_assets approved_digital_assets[] // auto-converted → ICP via Swap Engine
The Swap Engine converts all incoming tokens to ICP automatically under fixed, deterministic rules. No discretionary routing. No manual intervention.
Registration Window
The capital-formation entry function operates under two parallel registration windows, each closed by a deterministic protocol-enforced rule.
general_window slots 1,000,001 — 10,000,000 // closes at end of Month 48
cutoff_month 48 // 12 months before Year 5 settlement (Month 60)
The entry function MUST reject any registration request received past the founding-window-closure event for any caller attempting to enter as a founding-cohort participant; and MUST reject any registration request received past the general-window cutoff (end of Month 48) for any caller, regardless of the remaining capacity below the 10,000,000-participant cap.
Both closure events are time-sealed and irrevocable. No administrative override, emergency extension, or discretionary authority may re-open either window. The Month 48 cutoff is calculated from the canister's launch timestamp and is fixed in code at deployment; it cannot be modified post-launch.
Rationale. The Month 48 cutoff guarantees every participant has at least twelve months of locked-capital exposure before Year 5 settlement. Without it, a participant entering immediately before settlement would receive an equal pro-rata surplus share for capital appreciation they took no part in financing. The founding-cohort window is independent: it closes by participant count, not by date, and may close substantially before Month 48.
Day-1 Capital Architecture Allocation
Upon capital formation, funds are allocated into two permanently segregated pools. These boundaries are immutable at protocol level from the moment of allocation.
Pool Isolation Invariants
- No cross-pool transfers are permitted
- No pool may be merged, reclassified, or dynamically rebalanced
- No rehypothecation between pools
- No discretionary asset rotation
- Each pool must maintain independent accounting and settlement logic
- Capital Architecture structure is fixed from Day 1 through final settlement
Settlement Sequence (Year 5)
There are no daily distributions in the canonical protocol design. Daily VRF sealings occur every 24 hours but produce no payouts during the cycle — all 1,825 sealed daily-draw winners and all 275 sealed founding-draw winners are revealed and paid simultaneously at Year 5 settlement. The full settlement sequence is immutable:
Participant Settlement Events
A participant receives their final protocol output only upon one of these events:
- BTC allocation received — daily-draw or founding-draw VRF win, revealed and credited at Year 5 settlement under Scenario 3 (only if Profit clears the BTC Threshold).
- Year 5 pro rata distribution — every participant receives a pro rata share of the Pool Value at Year 5. Under Scenario 3, this is the cost-basis return plus 80% of residual profit pro rata. Under Scenario 2, this is the cost-basis return plus 80% of profit pro rata. Under Scenario 1, this is a pro rata share of the diminished pool (which may be less than $95 per participant).
BTC Allocation System
Daily BTC Engine — 1 BTC per day from Day 1, results sealed on-chain throughout the cycle, all winners paid at the Year 5 settlement.
Module A — Daily BTC Engine
From Day 1 of the protocol, the system executes one draw every 24 hours selecting 1 BTC winner. Each draw result is sealed on-chain immediately by VRF — cryptographically committed and publicly visible as a growing sealed count throughout the cycle. All daily draw winners are revealed at Year 5 settlement; whether they receive BTC depends on whether Year 5 Profit clears the BTC Threshold (Scenario 3). Under Scenarios 1 or 2, no BTC is purchased and sealed winners receive only their pro rata cash share.
- Draw runs from Day 1 — each result sealed on-chain immediately by VRF
- All 1,825 sealed daily draw winners revealed and paid simultaneously at the Year 5 settlement
- Daily VRF sealing executes every 24 hours regardless of treasury level — the BTC purchase threshold is checked once at Year 5 settlement only
- Selection via cryptographically verifiable randomness with pre-committed, time-sealed inputs
- No participant behaviour influences outcome
- BTC winners remain eligible for the Year 5 pro rata distribution — winning a draw does not exclude a participant. BTC winners receive 1 BTC on top of their pro rata cash share.
Module B — Founding Draw (275 BTC Sealed)
At the moment the 1,000,000th founding participant registers, an on-chain VRF executes automatically — selecting 275 winning wallets from the founding pool. Results are cryptographically sealed and invisible to all parties, including operators, until Year 5 settlement.
- VRF executes when 1,000,000th founding participant registers — 275 winners sealed from founding million, resolved at Year 5 settlement
- Results sealed on-chain immediately — invisible until Year 5 settlement
- At Year 5 settlement: all 275 sealed winners revealed simultaneously, each receives 1 BTC (275 winners total)
- Founding draw is exclusive to the founding million — closes permanently at slot 1,000,000
- Operates independently from the Daily BTC Engine draw schedule
Interaction with Year 5 Settlement
BTC is not allocated or purchased during the cycle. Daily VRF sealings produce sealed slots only — no BTC moves until Year 5 settlement, and only under Scenario 3. The full sequence at Year 5 is:
- Pool valued; profit calculated; BTC threshold tested.
- Under Scenario 3, 2,100 BTC purchased from profit at Year 5 market price; the cost of the BTC purchase is then subtracted from profit to compute Residual Profit.
- Residual Profit (Scenario 3) or Profit (Scenario 2) splits 80% to participants pro rata / 20% to founder Performance Fee.
- Every participant — winner or not — receives their pro rata cash share. BTC winners receive 1 BTC on top of their pro rata share.
The BTC system does not consume any portion of participant capital. Under Scenario 1 (Profit ≤ 0), no BTC is purchased and no Performance Fee is paid; participants share the diminished pool pro rata.
Year 5 Settlement
End-of-cycle reconciliation. Deterministic on-chain waterfall. No operator discretion.
Settlement Scope
At the end of the five-year cycle, the protocol reconciles according to the encoded rules committed at deployment. No operator discretion is permitted at settlement. The settlement executes deterministically on-chain.
Pool Valuation
Cost Basis = count(actual participants) × $95
Profit = Pool Value − Cost Basis
BTC Threshold = 2,100 × (Year 5 BTC price)
Three Scenarios
- Scenario 1 (Profit ≤ 0): Pool Value at or below Cost Basis. No BTC purchased. No Performance Fee paid. Participants share the diminished Pool Value pro rata. Sealed VRF winners receive no Bitcoin (because no Bitcoin is purchased) but receive the same pro rata pool share as every other participant.
- Scenario 2 (0 < Profit < BTC Threshold): Profit exists but is insufficient to fund 2,100 BTC at Year 5 BTC price. No BTC purchased. All Profit splits 80% to participants pro rata / 20% to founder Performance Fee. Every participant receives Cost Basis ($95) plus their pro rata share of 80% of Profit. Sealed winners receive no BTC.
- Scenario 3 (Profit ≥ BTC Threshold): 2,100 BTC purchased from Profit at Year 5 market price. Distribution: 275 BTC to founding-draw winners, 1,825 BTC to daily-draw winners. Residual Profit = Profit − BTC Threshold. Residual Profit splits 80% to participants pro rata / 20% to founder Performance Fee. BTC winners receive 1 BTC on top of their pro rata cash share.
Equal Treatment Rule
- No priority queue, no insider class, no seniority tier in the pro rata distribution
- BTC winners and non-winners receive identical pro rata shares of the cash distribution
- The 80/20 ratio is fixed at deployment and cannot be modified post-launch
- Settlement governed strictly by deterministic on-chain rules
Participant Capital Seniority
Participant capital is senior throughout. The $95 held in ICP for each participant is never used to purchase Bitcoin for another participant. Under every scenario, each participant receives their pro rata share of the Pool Value (whatever it has become) before any BTC is purchased or Performance Fee is paid. If the protocol is unprofitable, nobody wins Bitcoin — but no participant's capital has been consumed to pay Bitcoin to anyone else. Losses, where they occur, are caused by ICP market movement alone.
Operating Fee Reserve
$50M Operating Fee Reserve. Funds 5-year protocol operations only. Does not fund BTC prizes — Bitcoin is purchased exclusively from Participant Pool profit above cost basis.
Role & Function
The Operating Fee Reserve represents 5% of gross capital raised ($50M at full subscription). It is held in ICP alongside the Participant Pool and funds the protocol's operational obligations across the five-year cycle.
- Held in ICP across the five-year cycle
- Funds five-year operational costs only. Does not fund BTC prizes.
- Funds TriCert certification, Gibraltar compliance, development, infrastructure, legal, insurance, and operational overhead across the 5-year lifecycle (~$18M at full subscription)
- Any unspent Reserve at Year 5 flows into Pool Value before the settlement waterfall (per the canonical model)
- Operates under predefined spend rules encoded at launch
Operational Constraints
All 2,100 BTC (275 founding draw + 1,825 daily draws) are purchased exclusively from Participant Pool profit above Cost Basis at Year 5, and only under Scenario 3 (Profit ≥ BTC Threshold). The Operating Fee Reserve funds five-year operational costs only and does not fund BTC prizes. Any unspent Reserve at Year 5 rolls into the Pool Value before the settlement waterfall. There is no continuous BTC purchasing during the cycle — daily VRF sealings produce no payouts; all BTC moves once, at Year 5 settlement.
Operating costs scale with subscription — if fewer participants enter the protocol, the Reserve is proportionally smaller and operational scope is adjusted to match. The protocol is designed so operations never draw from the Participant Pool.
Performance Fee
20% of residual profit at Year 5. Calculated at settlement only. No upfront allocation. Paid only if Pool Value exceeds Cost Basis.
Definition
The Performance Fee is the founder's compensation for building and operating the protocol. It is calculated and paid only at Year 5 settlement, and only if the Participant Pool has appreciated above its cost basis. There is no pre-allocated Performance Fee pool, no management fee, no participation fee, and no carry on gross pool.
Calculation Logic
- Scenario 1 (Pool ≤ Cost Basis): Performance Fee = 0. Founder receives nothing. Participants share the diminished pool pro rata.
- Scenario 2 (Profit exists, insufficient for BTC purchase): Performance Fee = 20% × Profit. Remaining 80% distributed to participants pro rata.
- Scenario 3 (Profit sufficient for full 2,100 BTC purchase): 2,100 BTC purchased from profit at Year 5 market price. Performance Fee = 20% × Residual Profit (where Residual Profit = Profit − BTC Threshold). Remaining 80% of residual profit distributed to participants pro rata.
Realisation Constraints
A Performance Fee Realisation Event is a distinct lifecycle event triggered automatically by the Year 5 settlement sequence. Trigger conditions are defined in the governance specification at A5.
Alignment Properties
- Founder receives nothing if Pool Value ≤ Cost Basis — the founder bears the same downside trigger as participants
- Founder upside scales with the same Pool Value variable as participants
- No floor, no fixed payment, no minimum guarantee
- No impact on participant capital — Performance Fee is computed from profit only, never from cost basis
No Impact on Participant Rewards
The Performance Fee is calculated only after participants' pro rata distribution and any BTC purchase obligations have been met. Daily BTC allocation, the founding draw, and the participant pro rata distribution all operate completely independently of the founder's fee calculation.
5-Year Completion Cycle
Controlled, transparent multi-step closing sequence for the 10M/$1B campaign.
Closing Sequence
Year 5 Settlement Distribution
Deterministic scenario-based distribution at end of cycle. Performance Fee is 20% of residual profit; participants receive 80%.
Trigger Condition
Year 5 settlement triggers automatically at the end of the five-year cycle. The trigger is rule-based and deterministic — it cannot be manually activated, overridden, or discretionarily applied.
Distribution Logic — Scenario Branching
BTC Threshold = 2,100 × (Year 5 BTC price)
// Scenario 1: Profit ≤ 0
Performance Fee = 0
Per Participant Distribution = Pool Value ÷ Eligible Participants
// Scenario 2: 0 < Profit < BTC Threshold
Performance Fee = Profit × 20%
Per Participant Distribution = Cost Basis ($95) + (Profit × 80%) ÷ Eligible Participants
// Scenario 3: Profit ≥ BTC Threshold
BTC Purchase = 2,100 × (Year 5 BTC price)
Residual Profit = Profit − BTC Purchase
Performance Fee = Residual Profit × 20%
Per Participant Distribution = Cost Basis ($95) + (Residual Profit × 80%) ÷ Eligible Participants
Plus: 1 BTC each to 275 founding-draw winners + 1 BTC each to 1,825 daily-draw winners
// All eligible participants (up to 10,000,000) share the 80% pro rata.
// No class tiers. No multi-pool calculations. No discretionary weighting.
// BTC winners remain eligible for the pro rata cash share — winning a draw does not exclude a participant.
Eligibility Rules
- All participants who completed the $100 entry are eligible for the Year 5 pro rata distribution. There is no early exit; the participant set is fixed throughout the cycle.
- Daily-draw winners remain eligible for the pro rata cash distribution — the daily draw and the cash distribution are independent
- Founding-draw winners remain eligible for the pro rata cash distribution — the founding draw and the cash distribution are independent
- Founding-million participants who win in both the founding draw and the daily draw receive 2 BTC plus their pro rata cash share. The two draws are independent.
- Under Scenario 1, no BTC is purchased and no Performance Fee is paid; participants share the diminished Pool Value pro rata only. Sealed VRF winners receive no Bitcoin under Scenarios 1 or 2 (because no Bitcoin is purchased) but receive the same pro rata cash share as every other participant.
Storm Identity & Login System
Internet Identity authentication. Storm Username. Multi-asset wallet creation.
Authentication Layer
Participants authenticate using Internet Identity (ICP), replacing traditional username/password with secure device-based cryptographic login.
- Device-based cryptographic authentication
- Optional YubiKey / hardware security key support
- Multi-device identity recovery
- Passwordless access
Storm Username
System auto-generates a Storm Username on registration. Optional custom handles if available. Used for messaging, P2P payments, settlement notifications, and wallet identity abstraction — wallet addresses remain hidden behind the username.
@nikolas // custom handle
@satoshi // custom handle
Wallet Creation & Entry Flow
Storm Chat Platform
Unified messaging, wallet, payment, and protocol dashboard. Primary interface for the entire platform.
Core Features
One-to-one chat, group channels, protocol announcements, and settlement notifications — all via Storm usernames, never phone numbers or emails.
Send BTC directly to @usernames. System resolves username to correct wallet address automatically. Send BTC → @nikolas
Physical + virtual Storm Debit Card. Apple Pay / Google Pay compatible. BTC balances auto-converted to fiat at point of sale.
Real-time display of sealed VRF count, Pool Value, projected Year 5 outcome, and campaign progress. Daily VRF results are sealed and invisible until Year 5 reveal. All values read-only and on-chain verifiable.
Fiat Top-Up
Users may fund their Storm wallet via card payments, bank transfers, and regulated payment providers.
TriCert Credibility Architecture
Three independent certification layers. Funded from the Operating Fee Reserve (canonical model: ~$1.4M for TriCert programme).
Certification Layers
- Deterministic architecture, no hidden execution paths
- Auditable settlement logic
- Isolated risk domains: swap → treasury acquisition → ICP holding → settlement
- Full attack-surface hardening
- Event logs for every deterministic process
- Verifiable payout pipelines aligned with the canonical economic model
- MPC wallet routing compatibility
- Segregated hot/cold paths
- Insured custody hooks
- Audit-grade transaction logs
- Proof-of-reserve compatibility
- Multi-sig fallback models
- Fully deterministic capital architecture
- Transparent, traceable settlement architecture
- Economic invariants for every payout flow
- Verifiable BTC threshold and Year 5 settlement waterfall
- Strict separation: participant capital / founder Performance Fee / reserves
- Long-form mathematical annotations per function
Engineering Deliverable
A codebase and architecture that is simultaneously:
- Audit-ready — structured for Tier-1 crypto security review without redesign
- Custody-ready — SOC-certified custodian can attach directly
- Verification-ready — independently verifiable by Big-4 financial auditors
- Operationally transparent — all flows on-chain traceable
- Certifiable by Tier-1 global firms across all three layers
Fiat On-Ramp Infrastructure
Compliant fiat access stack supporting entry by participants who do not already hold whitelisted on-chain assets. No token is issued at launch.
No Token at Launch
Fiat On-Ramp Infrastructure
The build team will integrate a compliant fiat access stack supporting:
- Card payments (Visa / Mastercard)
- SEPA transfers (EU / UK)
- Wire transfers / bank deposits
- Automated fiat → approved on-ramp asset → protocol-treasury swap routing
- KYC / AML compliance
- Custodial handling for pending fiat deposits
- Direct integration with Bitcoin Storm App and Swap Engine
A regulated third-party provider is acceptable if required. Users must be able to enter Bitcoin Storm directly with fiat, with the on-ramp converting fiat into a whitelisted on-chain asset which is then swapped into the protocol treasury under encoded protocol rules.
Engineering Mandate
Delivery Milestones & Phase Timeline
Phased build schedule from token creation through Year 5 settlement. Each phase has defined deliverables and acceptance criteria.
Phase 0 — Foundation (Pre-Launch)
- Internet Identity integration — Storm Username generation, multi-device recovery
- Wallet infrastructure — BTC and ICP multi-asset environment
- Fiat on-ramp integration — KYC/AML layer, card and bank deposit routing
- Swap Engine MVP — whitelisted token → ICP conversion under deterministic rules
- TriCert Layer 1 readiness — codebase prepared for security audit submission
Phase 1 — Capital Formation Engine
- Capital Architecture pool architecture — two segregated pools with immutable boundaries
- Capital intake routing — swap → ICP → pool allocation under fixed rules
- Operating Fee Reserve segregation — Operating Fee Reserve held in ICP throughout the cycle, accounting tracked independently from Participant Pool, non-withdrawable except for authorised operational expenses under predefined spend rules
- On-chain pool accounting — public, verifiable, independently auditable
- TriCert Layer 2 readiness — custody infrastructure integration certified
Phase 2 — Engine Activation (Year 1)
- Daily VRF sealing engine live — one slot sealed every 24 hours from Day 1; each result committed on-chain immediately and invisible until Year 5; all winners paid at Year 5 settlement under Scenario 3 only
- Founding draw VRF — automatic trigger at the moment the 1,000,000th founding participant registers; 275 winning slots sealed against the founding-million universe
- Storm Chat platform — identity, messaging, wallet, dashboard live
- Real-time protocol dashboard — Pool Value, Cost Basis, projected Year 5 outcome (Scenario), sealed daily-slot count
- TriCert Layer 3 readiness — economic model independently verified
Phase 3 — Steady-State Operations (Years 1–4)
- Daily VRF sealings continue uninterrupted — one slot sealed per 24 hours throughout the cycle
- Pool held in ICP with no discretionary trading or rebalancing
- Operating Fee Reserve consumed under predefined spend rules
- Ongoing TriCert monitoring and post-audit patch cycles
- Founding draw closes permanently at slot 1,000,000 (timing depends on registration pace)
Phase 4 — Year 5 Settlement Preparation
- Snapshot lock activation — participant set permanently fixed at end of Year 5
- Final daily VRF sealing — last of the 1,825 daily slots sealed on-chain
- Pool valuation — Pool Value = (ICP held) × (Year 5 ICP price) + (unspent Operating Fee Reserve balance)
- Cost Basis computation — Cost Basis = actual participant count × $95
- Profit and threshold test — Profit = Pool Value − Cost Basis; BTC Threshold = 2,100 × (Year 5 BTC price); Scenario determined
Phase 5 — Year 5 Settlement Execution & Engine Close
- Sealed VRF reveal — all 275 founding-draw and 1,825 daily-draw winners revealed simultaneously and recorded on-chain; unfilled slots re-drawn against actual participant set
- BTC purchase (Scenario 3 only) — 2,100 BTC purchased from profit at Year 5 market price; 275 BTC paid to founding-draw winners, 1,825 BTC paid to daily-draw winners
- Pro rata cash distribution — every participant receives their pro rata cash share per the canonical waterfall (Scenario 1: diminished pool only; Scenario 2: cost basis + 80% of profit pro rata; Scenario 3: cost basis + 80% of residual profit pro rata)
- Performance Fee payout (Scenarios 2 and 3 only) — 20% of profit (Scenario 2) or 20% of residual profit (Scenario 3) paid to founder. Under Scenario 1, no Performance Fee.
- Engine close — system formally settled and decommissioned; on-chain settlement event records all values
VRF Technical Specification
Verifiable Random Function implementation requirements for BTC allocation.
Approved VRF Options
The Internet Computer provides protocol-native threshold randomness generated by the subnet consensus mechanism. Preferred approach — eliminates external oracle dependency, is verifiable on-chain, and is natively integrated with canister execution.
- No external oracle service fees or availability risk
- Randomness generated at subnet level — not controllable by any single party
- Directly accessible via ICP canister API
- Pre-commitment via timestamp seed anchoring at epoch start
If ICP native randomness is deemed insufficient for the required cryptographic proof standard, Chainlink VRF provides a widely-audited, publicly-verifiable alternative with on-chain proof of correctness.
- Requires cross-chain bridge or compatible integration layer
- Additional operational cost per randomness request
- VRF proof publicly verifiable on-chain
- Used by major on-chain lottery and gaming protocols
Mandatory VRF Requirements
- Pre-commitment — randomness seed must be committed on-chain before the selection window opens
- Time-sealing — seed locked to a specific epoch or block; no re-seeding after commitment
- Forward-linking — each epoch's seed must cryptographically reference the previous epoch
- Public verifiability — any participant must be able to independently verify the selection output
- Admin-proof — no operator, developer, or founder can influence, reseed, or override committed randomness
- Audit trail — every randomness event must be logged with timestamp, seed, output, and participant set snapshot
Randomness Usage by System
| System | Frequency | Participant Set | Output |
|---|---|---|---|
| Daily BTC Engine | Once per operational day | All non-exited participants | 1 winner selected |
| Founding Draw (275 BTC) | Sealed at slot 1,000,000 — resolved at Year 5 | Founding million participants | 275 sealed winners — revealed at Year 5 settlement |
Engineering Requirement
The build team must specify the chosen VRF implementation in the engineering contract, provide a technical justification, and ensure the chosen approach is compatible with TriCert Layer 1 security audit requirements. The VRF implementation must be explicitly reviewed and approved as part of the security certification process.
Fiat On-Ramp — Operational Specification
KYC jurisdiction, pending deposit handling, failed transaction logic, and conversion rules.
KYC / AML Jurisdiction & Standard
- Primary jurisdiction — compliance must meet EU AMLD6 and UK FCA standards as a minimum baseline
- KYC tier — full identity verification (photo ID + liveness check) required for all participants prior to swap execution
- Sanctioned jurisdictions — OFAC, EU, and UN sanctions lists must be screened at entry; blocked jurisdictions cannot participate
- Ongoing monitoring — AML transaction monitoring must be active for the full 5-year cycle
- Third-party provider — if a regulated provider handles KYC/AML, they must be a licensed VASP or equivalent; provider name and licence number to be specified in contract
Pending Fiat Deposit Handling
- Fiat deposits held in a segregated client money account pending conversion — never commingled with protocol capital
- Maximum holding period for pending deposits: 3 business days before conversion must execute or deposit is returned
- Participant is not allocated a Storm position until fiat → whitelisted asset conversion is confirmed and swap execution into the protocol treasury completes
- Partial deposits not accepted — the full $100 equivalent must be received before entry is initiated
Failed & Reversed Transaction Logic
System must retry conversion up to 3 times within a 24-hour window. If all retries fail, fiat is returned to originating account within 5 business days. No Storm position is allocated. KYC record is retained.
If a chargeback or reversal is received after Storm position has been allocated: the participant's position is immediately frozen pending resolution. System flags account for manual review. If reversal is confirmed valid, position is voided and the swapped asset equivalent is unwound from the pool at prevailing market rate.
If KYC verification fails after deposit is received, fiat is held in escrow and returned within 5 business days. No position is allocated. If KYC failure occurs after position allocation (delayed check), position is frozen and queued for manual compliance review.
Conversion Rate & Timing
- Conversion from fiat to ICP executes at the prevailing spot rate at time of confirmation — no rate guarantees are made to participants
- Rate slippage tolerance: maximum 2% from quoted rate; if exceeded, conversion pauses and participant is notified
- All conversion rates and execution timestamps must be logged on-chain alongside participant records
Error Handling & Edge Cases
Deterministic behaviour rules for system failures, oracle unavailability, surplus shortfalls, and timing edge cases.
Swap Engine Failures
If the Swap Engine fails after receiving tokens but before completing ICP conversion: the incoming tokens are held in a quarantine wallet. System retries conversion automatically at the next available epoch (maximum 3 retries in 24 hours). If all retries fail, tokens are returned to originating wallet and no position is allocated. All events must be logged with full state at time of failure.
If conversion yields less than $95 USD-equivalent of ICP (accounting for slippage): swap is rejected, tokens returned, and participant must resubmit. The $100 minimum is enforced at the ICP received value, not the token submitted value.
VRF Oracle Unavailability
If VRF randomness cannot be generated for a scheduled daily sealing: the sealing is retried at the next available block within the same 24-hour window. If sealing cannot be completed within 24 hours, the missed slot is sealed at Year 5 against the actual participant universe alongside any other unfilled slots. No daily slot is permanently lost. All retry events are logged publicly on-chain.
Daily VRF sealing executes every 24 hours regardless of treasury level. The treasury threshold is checked once at Year 5 settlement only — never during the cycle. If the threshold is not cleared at Year 5, no BTC is purchased and no daily-draw winners receive BTC; participants share the diminished pool pro rata per Scenario 1.
Year 5 Threshold Not Met
The treasury threshold is evaluated only at Year 5 settlement. If Profit ≤ 0 (Scenario 1), participants share the diminished pool pro rata; no BTC is purchased and no Performance Fee is paid. If 0 < Profit < BTC Threshold (Scenario 2), no BTC is purchased; all profit flows into the pro rata cash distribution (80% participants / 20% founder). Sealed daily and founding draw winners receive no BTC under Scenarios 1 or 2 — but receive the same pro rata pool share as every other participant. This is reported in real time on the protocol dashboard throughout the cycle as projected Year 5 outcome.
ICP Network Downtime
- If the ICP network experiences downtime of less than 6 hours: all scheduled operations resume automatically upon recovery; no state changes occur during downtime
- If downtime exceeds 6 hours: the day's distribution events are skipped entirely; state remains at last confirmed checkpoint; no retroactive distributions for missed days
- All downtime events are logged publicly; participants are notified via Storm Chat and protocol dashboard
- Extended downtime (>48 hours) triggers an operational review under the Pause Mechanism (see A6)
Duplicate / Double-Entry Attempts
- Internet Identity ensures one verified identity per participant — duplicate entry attempts are rejected at the identity layer
- A second swap from the same verified identity is rejected by the engine; tokens returned to sender
- Attempts to create multiple Internet Identity anchors to bypass the one-entry rule must be detected and flagged by the KYC layer
Performance Fee Realisation Governance Specification
Defines the conditions, authority, and process for triggering a Performance Fee Realisation Event. Referenced throughout Functions 1, 7, and 9.
What a Performance Fee Realisation Event Is
A Performance Fee Realisation Event is the calculation and payment of the founder's 20% share of profit at Year 5 settlement. It is the only mechanism by which founder Performance Fee may be accessed, converted, or distributed. It is rule-based, deterministic, and triggered only by the Year 5 settlement sequence.
Permitted Trigger Conditions
- T1Year 5 Settlement (Sole Trigger) — at the end of the five-year cycle, the Performance Fee is calculated as 20% of residual profit and paid as part of the Year 5 settlement sequence. The Performance Fee is paid only if Pool Value exceeds Cost Basis. If the protocol is unprofitable, no Performance Fee is paid.
- T2Protocol Emergency Wind-Down (Restricted) — if a critical security vulnerability is confirmed by TriCert auditors requiring an emergency wind-down to protect participants, the protocol enters wind-down per A6. No Performance Fee is paid in a wind-down scenario. The remaining treasury is liquidated and distributed pro rata to participants only.
Prohibited Trigger Conditions
- Performance Fee Realisation may never be triggered before Year 5 settlement
- Performance Fee Realisation may never be triggered by daily surplus calculations — there are no daily surplus calculations in the canonical protocol design
- Performance Fee Realisation may never be triggered by interim treasury appreciation, capital preservation thresholds, or concentration risk events — the founder's fee is computed at Year 5 only, from final residual profit only
- No engineer, founder, operator, or system administrator may trigger Performance Fee Realisation unilaterally or ahead of Year 5
Engineering Implementation Requirements
- The Performance Fee is computed at Year 5 settlement — there is no pre-allocated Performance Fee wallet to fund or guard during the operational lifecycle
- The Year 5 settlement payout must be implemented as a deterministic on-chain calculation: Performance Fee = max(0, 0.20 × Residual Profit). Residual Profit is defined per Function F7.
- The settlement transaction must emit a public on-chain event recording: Pool Value, Cost Basis, Profit, BTC Threshold, BTC purchased, Residual Profit, Performance Fee amount, and per-participant pro rata distribution amount
- The Operating Fee Reserve accounting system must maintain independent balance tracking separate from all participant-attributable ICP at all times, so that any unspent Reserve at Year 5 can be cleanly added to Pool Value before the waterfall executes
Disaster Recovery & System Pause Mechanism
Defined conditions for engine halt, audit mode, and controlled recovery. Balances operational safety with invariant integrity.
Pause Authority Structure
The system pause mechanism is governed by a 3-of-5 multi-sig governance key held by:
- Bitcoin Storm Founder (1 key)
- Lead TriCert Security Auditor (1 key)
- Independent Legal Counsel (1 key)
- Bitcoin Storm Operations Lead (1 key)
- Engineering Lead (1 key — engineering authority only, not economic authority)
No single key holder can pause the system unilaterally. 3 of 5 must sign. Key assignments are published on-chain and cannot be changed without a public 72-hour notice period.
Permitted Pause Triggers
- Confirmed smart contract exploit — active attack or confirmed critical vulnerability affecting capital security
- ICP network instability — subnet downtime exceeding 48 consecutive hours
- Regulatory order — valid legal order from a competent jurisdiction requiring system halt
- Custodian compromise — confirmed compromise of the custody infrastructure (Layer 2 TriCert)
What Pause Does and Does Not Do
- All daily distributions halt immediately
- New participant entries are blocked
- Capital remains locked in capital architecture — no movement permitted
- Protocol dashboard remains live showing pause status and reason
- Storm Chat messaging remains operational
- Pause cannot move, access, or redistribute participant capital
- Pause cannot alter pool boundaries or Capital Architecture allocations
- Pause cannot modify randomness seeds or BTC ledger commitments
- Pause cannot change payout sequencing rules
- Pause cannot extend the 5-year operational cycle
Recovery Protocol
Testing & Audit Environment Specification
Pre-launch testing requirements, simulation environment, stress testing, and staging criteria before mainnet activation.
Testnet Requirements
The build team must deploy and maintain a full-fidelity staging environment on ICP testnet that replicates the production architecture exactly:
- All 12 core functions operational in staging before mainnet deployment
- Capital Architecture pool architecture with simulated capital flows
- VRF randomness using testnet-equivalent entropy source
- Simulated participant accounts at scale (minimum 10,000 test identities)
- All TriCert audit work must reference the staging environment codebase — not isolated test files
Economic Model Simulation
Before mainnet launch, the economic engine must be stress-tested under the following scenarios:
| Scenario | ICP Price | Participants | Pass Criteria |
|---|---|---|---|
| Bear Case | −80% from entry price | 10M | Scenario 1 activates: Pool Value below Cost Basis; no profit; no BTC purchased; sealed BTC winners receive no Bitcoin (because no Bitcoin is purchased) but receive the same pro rata pool share as every other participant; no Performance Fee paid |
| Base Case | +100% from entry | 10M | Scenario 3 activates: Profit clears the BTC threshold; 2,100 BTC purchased; residual profit splits 80/20; participants receive cost basis plus residual profit share, BTC winners receive 1 BTC additional |
| Marginal Profit Case | +10–15% from entry | 10M | Scenario 2 activates: Profit exists but insufficient to fund 2,100 BTC at Year 5 BTC price; no BTC purchased; all profit flows into 80/20 split; sealed BTC winners receive no Bitcoin but receive the same pro rata share as every other participant |
| Bull Case | +1000% from entry | 10M | Scenario 3 activates: 2,100 BTC purchased; residual profit splits 80/20; per-participant pro rata distribution computes correctly; BTC winners credited 1 BTC on top of pro rata share |
| Oracle Failure | Any | 10M | System skips distribution cleanly; state preserved |
Pre-Launch Acceptance Criteria
The following gates must all be cleared before mainnet activation is permitted:
- G1TriCert Layer 1 complete — security audit passed with all critical/high findings resolved
- G2TriCert Layer 2 complete — custody infrastructure certified by licensed custodian
- G3TriCert Layer 3 complete — economic model verified by Big-4 firm
- G4Full simulation suite passed — all five stress-test scenarios above pass without manual intervention
- G5Multi-sig governance keys — all 5 key holders confirmed and keys generated; 3-of-5 test transaction executed successfully
- G6Geofencing & KYC live — jurisdictional restriction enforced at the access layer, KYC/AML pipeline operational, sanctions screening verified
- G7Fiat on-ramp live — end-to-end test transactions completed for card, SEPA, and wire
- G8Dashboard live — all protocol metrics visible, all on-chain data accurately reflected in real time
Post-Launch Monitoring Requirements
- Real-time alerting for any distribution failure, missed draw, or oracle error
- Daily automated reconciliation: pool balances vs expected model values
- Weekly on-chain audit log review by TriCert security team during Year 1
- Quarterly economic model review by Big-4 verification firm throughout the 5-year cycle
- Incident response SLA: critical issues acknowledged within 2 hours, patch deployed within 24 hours
Build Integrity & Anti-Tampering
Counterparty controls applied across the engineering engagement. The risks below are documented because they are real, not because they are anticipated of any specific party.
A8.1 Threat Categories the Build Process Must Defend Against
The following are documented attack patterns from prior crypto-asset deployments. They are listed not as accusations but as the threat surface the engineering process must close:
- Hidden code paths in the production canister — backdoor addresses, conditional logic gated on user count or time, off-by-one errors in distribution arithmetic that compound over the cycle, dormant functions activated by external input.
- Last-minute commit substitution — a clean version is audited; a different version is deployed.
- Hardcoded destination addresses substituted for the founder's specified addresses — a single character change in the participant pool, Performance Fee, charity, or marketing destinations renders that flow unrecoverable for five years.
- Malicious dependency injection — a compromised library, build artifact, or VRF integration introduces external behaviour the audit didn't see.
- Governance-key concentration — upgrade authority, pause authority, or admin keys held by fewer parties than specified, or held by the same party under different roles.
A8.2 Repository Discipline
- All code lives in a repository visible to the founder from week one. Read access for the founder and a nominated independent reviewer is non-negotiable.
- Every commit is GPG-signed by a named individual. Anonymous commits, shared accounts, and unsigned commits are rejected at merge.
- No force-pushes to main, develop, or any release branch. Branch protection enforced at the repository level.
- All merges to a release branch require approval from a second engineer not employed by the same vendor as the author. Self-merges are rejected.
- The commit graph is preserved permanently. No history rewrites, squashes that erase author trails, or tag movements after publication.
A8.3 Deterministic Builds
The production canister WASM produced by the build process must be byte-for-byte reproducible from any clean checkout of the named commit. The engineering team must publish, alongside each release candidate:
- The exact commit hash.
- The build environment (Rust version, dfx version, OS, all toolchain pins).
- The expected SHA-256 of the produced WASM.
- Build instructions a third party can follow to verify the hash matches.
Reproducibility is an acceptance criterion, not an aspiration. A build that cannot be independently reproduced from source cannot be promoted to mainnet.
A8.4 Witnessed Deployment Ceremony
Promotion of the audited build to the production canister ID will be performed in a recorded session attended by, at minimum:
- The engineering lead performing the deployment.
- The founder or the founder's nominated representative.
- The third-party security auditor who signed off on the commit.
- One independent observer (legal counsel or compliance officer).
The session records, in order: the commit hash being deployed; the locally-built WASM SHA-256; the on-chain canister hash after deployment; the verification that all three match. Only after that match is confirmed does the controller-removal step proceed. The recording is retained as part of the audit record.
A8.5 Hardcoded Address Verification
Destination addresses for the participant pool, Performance Fee receiving wallet, charity wallet, and any other hardcoded recipient are verified by the following procedure before the canister is set immutable:
- Each address is read aloud by one party, transcribed by a second, confirmed character-by-character by a third, against the source the founder provided.
- Verification is performed at least twice, with at least 24 hours between attempts, by the same parties.
- Each destination wallet is exercised before lockdown: a small test transaction is sent in, then a small test transaction is sent out, demonstrating end-to-end control by the named recipient.
- The address that goes into the canister source is then compared byte-for-byte against the address used in the test transactions. Any discrepancy is escalated and verified by the founder in writing before deployment proceeds.
The founder's receiving wallets for the Performance Fee will be multi-signature wallets requiring a quorum to move funds. The engineering team encodes the address; signing arrangements are off-protocol and not the engineering team's concern. What matters at the canister level is that the address is correct.
A8.6 Pre-Lockdown End-to-End Test
Before the controller is removed, the production canister must be exercised against real (small) value on mainnet with a closed cohort of test participants:
- 10 to 100 test participants pay a fraction of the real entry value into the production canister.
- Every distribution code path runs against the real test cohort: capital allocation, BTC engine seeding, daily VRF sealing, time-fast-forwarded Year 5 settlement simulation.
- Every payment lands in the correct destination wallet. Any deviation, however small, halts deployment.
- The test is repeated at least twice, with the auditor observing.
- The exact commit that passes the end-to-end test is the only commit eligible for production promotion. A one-line change "for code quality" between the test pass and promotion invalidates the test and the audit.
A8.7 Independent Audit as Acceptance Gate
The build is not "complete" on Blockchain SL's certification alone. An independent third-party audit by a firm with public Internet Computer audit experience (Trail of Bits, NCC Group, Halborn, or equivalent on similar tier) must:
- Be retained and contracted directly by the founder, not by the engineering team.
- Have unrestricted read access to the repository for the duration of the engagement.
- Produce a written report against the named commit hash.
- Sign off in writing on the exact commit hash eligible for production promotion.
Audit findings above low severity must be remediated and re-audited before deployment. Audit cost and timeline are budgeted separately from the engineering build program; the engineering team cooperates with the audit but is not the audited party in the formal sense.
A8.8 Continuous Post-Launch Monitoring
From the moment the canister is set immutable until Year 5 settlement closes, the production canister state and all hardcoded destination wallets are subject to continuous on-chain monitoring. Anomalous canister state changes, unexpected fund movements out of destination wallets, or VRF entropy deviations must alert the founder, the engineering lead, and the security auditor within minutes. Monitoring tooling (TRM Labs, Chainalysis KYT, or equivalent) is contracted independently of the engineering team.
A8.9 Engineering Liability and Engagement Terms
The engineering engagement letter with Blockchain SL will include, at minimum: a defined liability cap negotiated in writing (the standard fees-multiple cap is typical); a warranty that no developer has, at any point, included undocumented code paths in the production canister; a requirement to disclose any subcontractor or third-party contributor with commit access; and an obligation to cooperate fully with the third-party audit. These are commercial terms in the engagement letter, not protocol invariants, but they are in scope of the relationship and listed here so the engineering team is aware of them at the point of contracting.