> For the complete documentation index, see [llms.txt](https://baca.endhonesa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://baca.endhonesa.com/all-notas-markdowns/archived-oioi/2026/01/20260112-bgc-iblooming-simulation-doc.md). # BGC X IBLOOMING SIMULATION DOC V0.1 > Status: Draft v0.1 — For internal use by BGC × iBLOOMING founders & core team.\ > Author: Prof. NOTA v.11.11\ > Scope: Phase-1 Simulation for ALPHA Layer & Reward Sustainability *** ## 1. Purpose & Context This document defines the simulation plan for the BGC × iBLOOMING integration. Its main purposes are: * To **translate 24-month historical data** (PC, SP, rewards, cash-outs, user behaviour) into a simulation model. * To **derive sustainable parameter ranges** for: * PC/SP → ALPHA conversions, * reward allocation and sinks, * cash-out windows and thresholds, * treasury protection and risk limits. * To provide **data-backed input** for: * [WHITEPAPER v1 (draft)](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=307NXv8YeYMxsWTZaV5z\&only=yes\&limit=100) (final wording and numbers), * [TOKENFLOW v1 (draft)](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=USH0cBRq7yGXLwTmmFDJ\&only=yes\&limit=100) (final formulas and guards), * ALPHA Implementation Blueprint (contract-level rules). This Simulation Doc reads together with: * [**LIVING Doc**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?limit=100\&only=yes\&page=ijQlNvGkp9UTE2LR2Tjm) (strategic context & execution pillars), * [**UNDERSTANDING Doc**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=4Eh8GomcmSGx85uX6sBg\&only=yes\&limit=100) (AS-IS model), * [**WHITEPAPER Doc (draft)**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=307NXv8YeYMxsWTZaV5z\&only=yes\&limit=100), * [**TOKENFLOW Doc (draft)**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=USH0cBRq7yGXLwTmmFDJ\&only=yes\&limit=100). *** ## 2. Scope & Non-Scope ### 2.1 In Scope * Phase-1 **ALPHA Layer simulation**, using real BGC × iBLOOMING operational data. * Modeling of: * PC/SP generation and consumption, * reward accrual and distribution, * member cash-out behaviour, * affiliate network growth patterns. * Parameter exploration for: * ALPHA issuance, * reward caps/limits, * cash-out frequency, thresholds, and fees, * ALPHA sinks and utility events. * Measuring **sustainability**, **fairness**, and **operational load**. ### 2.2 Out of Scope (for v0.1) * UX design and UI flows. * Final smart contract implementation details (covered in ALPHA Blueprint). * Public token market dynamics (iBC/iBTC trading, order books, etc.). * Long-term legal structuring beyond the assumptions needed for Phase-1. *** ## 3. Data Sources & Assumptions ### 3.1 Data Sources (24-Month Window) * BGC transaction logs: * PC (Purchase Credit) events, * SP (Sales Point) events, * Membership tiers (Pathfinder, Voyager, etc.), * e-wallet balances and movements, * cash-out requests and actual payouts (weekly cycles). * iBLOOMING product & engagement data: * course purchases, * feature usage, * campaign-based boosts (if any). * Aggregated affiliate network stats: * number of active members, * churn/retention, * average earnings per segment. ### 3.2 Key Assumptions * Data is sufficiently clean to support scenario modeling (minor anomalies will be noted). * AS-IS reward rules from [**UNDERSTANDING Doc**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=4Eh8GomcmSGx85uX6sBg\&only=yes\&limit=100) are taken as **baseline behaviour**. * No new external shocks (e.g. regulation bans) are assumed in v0.1 scenarios. * Public token (iBC/iBTC) will be derived **after** ALPHA layer validation. *** ## 4. Simulation Model Overview ### 4.1 Entities * **Member**: an individual with PC/SP history, wallet balance, and cash-out actions. * **Event**: * PC creation, * SP creation, * reward accrual, * bonus/top-up, * cash-out request, * on-hold / rejected events (if any). * **ALPHA Ledger** (virtual in v0.1): * ALPHA-earned, * ALPHA-spent/locked, * ALPHA-equivalent of existing rewards. ### 4.2 Time Resolution * Base time unit: **monthly**, with the ability to drill down to **weekly** if needed. * Simulation horizon: **24 months historical**, plus **projected 12–24 months** (optional). ### 4.3 State Variables Examples: * Total PC, total SP, and their distributions. * Reward obligations (outstanding, paid, pending). * Member-level balances and cash-out frequency. * Simulated ALPHA supply: * issued, * locked, * available for spend. *** ## 5. Parameters to Explore (v0.1) This section lists the parameters that will be explored through simulation.\ Each parameter will have: **Name, Symbol, Description, Range, Default, Decision Owner**. ### 5.1 Conversion Parameters (PC/SP → ALPHA) #### 5.1.1 Parameter Table — Conversion | Name | Symbol | Description | Range (for simulation) | Default | Decision Owner | | -------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | ------- | -------------------------- | | PC→ALPHA multiplier (per 100 PC) | `k_PC` | ALPHA minted when **100 PC** is converted (100 PC = 1 USD in [UNDERSTANDING Doc](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=4Eh8GomcmSGx85uX6sBg\&only=yes\&limit=100)). | 0.5 – 1.5 ALPHA per 100 PC | 1.0 | Founders + Tokenomics | | SP→ALPHA multiplier (per 1 SP) | `k_SP` | ALPHA minted per **1 SP** (1 SP = 1 USD reward basis). | 0.5 – 1.5 ALPHA per SP | 1.0 | Founders + Tokenomics | | Tier bonus multiplier (max) | `m_tier` | Max multiplier between lowest and highest Affiliate tiers (Pathfinder → Special). | 1.0 – 2.0 (relative to base tier) | 1.5 | Tokenomics (with founders) | | Campaign boost multiplier (max) | `m_camp` | Max temporary boost for special campaigns or promos (applied on top of base conversion). | 1.0 – 3.0 (no boost → aggressive boost) | 2.0 | Tokenomics + Marketing | | User ALPHA cap per month | `cap_u` | Soft cap for ALPHA minted per user per month, relative to **95th percentile** user-month. | 3× – 10× P95 baseline | 5× P95 | Tokenomics + Finance | | Group ALPHA cap per month | `cap_g` | Soft cap for ALPHA minted per group/team per month, relative to **99th percentile** group. | 2× – 5× P99 baseline | 3× P99 | Tokenomics + Finance | * `k_PC` — PC-to-ALPHA multiplier. * `k_SP` — SP-to-ALPHA multiplier. * Tier-based modifiers for: * rank, * product type, * campaign. * Caps per period: * max ALPHA per user per month, * max ALPHA per group per month. * `cap_u` and `cap_g` use percentile data, so they don't need absolute numbers first. ### 5.2 Reward & Treasury Parameters #### 5.2.1 Parameter Table — Reward & Treasury | Name | Symbol | Description | Range (for simulation) | Default | Decision Owner | | ---------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | ------- | --------------------- | | Global reward intensity factor | `R_global` | Global scaling factor for all reward shares (RR/GR/GPSP/WEC, etc.) relative to AS-IS. | 0.7 – 1.3 (70% – 130% of AS-IS) | 1.0 | Founders + Tokenomics | | Pool reward intensity factor | `R_pool` | Specific factors for pools (GPSP, WEC, GMP, GEC) vs direct rewards. | 0.7 – 1.3 | 1.0 | Founders + Tokenomics | | Target ALPHA sink utilisation | `S_target` | Expected percentage of ALPHA **consumed** (classes, features, boosts, CP products, etc.). | 0.40 – 0.80 (40% – 80% of minted) | 0.60 | Tokenomics + Product | | Minimum treasury runway (months) | `T_runway` | The minimum number of months of reward obligations that a treasury must be able to cover before being considered “unsafe.” | 3 – 12 months | 6 | Founders + Finance | | Emergency throttle runway (months) | `T_emerg` | The runway level at which the throttle/economy mechanism begins to engage | 1 – 3 months | 2 | Founders + Finance | | Max monthly payout vs inflow ratio | `T_payoutMax` | Maximum ratio (payout/inflow) before throttle (i.e. hold part of payout to the next window). | 0.70 – 1.10 (70% – 110% of inflow) | 0.90 | Tokenomics + Finance | * Reward share splits (RR/GR/GPSP/etc., as represented in ALPHA). * ALPHA sinks: * classes, * boosts, * CP digital products, * special campaigns. * Treasury buffers: * minimum reserve ratio, * emergency throttle rules. * The main idea: we can see the runway & payout ratio graph for each scenario, then the Founders can say, “we are comfortable with 6 months runway and payout ≤ 90% inflow” or ask for a change. ### 5.3 Cash-Out Parameters #### 5.3.1 Parameter Table — Cash-Out | Name | Symbol | Description | Range (for simulation) | Default | Decision Owner | | ----------------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------- | --------------------------- | ------------- | --------------------- | | Minimum cash-out amount (USD) | `C_min_usd` | Minimum balance that can be cashed out in one request. | 50 – 150 USD | 100 USD | Founders + Finance | | Cash-out fee (basis points) | `C_fee_bps` | Fee % for each cash-out (1% = 100 bps). | 0 – 300 bps (0% – 3%) | 100 bps (1%) | Founders + Finance | | Cash-out mode | `C_mode` | Main mode: **ALWAYS\_OPEN** (like the existing model) or **WINDOWS** (pilot-style). | {`ALWAYS_OPEN`, `WINDOWS`} | `ALWAYS_OPEN` | Founders | | Number of cash-out windows per year | `C_win_year` | If `C_mode = WINDOWS`: number of windows in a year. | 4 – 52 (e.g. 4, 12, 24, 52) | 4 (quarterly) | Founders + Tokenomics | | Window length (days) | `C_win_days` | If `C_mode = WINDOWS`: duration of each window. | 1 – 30 days | 7 days | Founders + Tokenomics | | Processing lag (days) | `C_lag_days` | The time from when the cash-out request is approved until the funds actually reach the user's bank account. | 1 – 14 days | 7 days | Ops + Finance | | Cooling-off after large cash-out | `C_cooloff` | The number of days before a user can make their next large cash-out (anti-abuse / liquidity shock). | 0 – 30 days | 7 days | Founders + Tokenomics | * Minimum cash-out amount (e.g. 50–100 USD equivalent). * Cash-out frequency: * weekly processing (AS-IS), * windows vs always-open behaviour. * Cash-out fees: * percentage fee range, * fixed fee (if any). * Cooling-off rules (anti-abuse). * How to use in simulation: * AS-IS scenario: `C_mode = ALWAYS_OPEN`, `C_min_usd = 100`, `C_fee_bps ≈ 0–100`, `C_win_year` & `C_win_days` ignored. * Windows Pilot Scenario: `C_mode = WINDOWS`, `C_win_year = 4`, `C_win_days = 7`, `C_min_usd = 50`, `C_fee_bps = 100`. ### 5.4 Web3-Related Operational Parameters (Phase-1 Touchpoints) #### 5.4.1 Parameter Table — Web3 Ops (Gas & Anti-Sybil) | Name | Symbol | Description | Range (for simulation) | Default | Decision Owner | | ---------------------------------------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------- | -------- | ------------------------- | | Per-user daily gas sponsorship cap (USD) | `G_user_daily_usd` | Maximum limit of estimated sponsored gas costs per user per day. | 0.05 – 0.25 USD | 0.10 USD | Founders + Tech + Finance | | Global daily gas sponsorship cap (USD) | `G_global_daily_usd` | Maximum gas sponsorship limit for the entire system per day. | 20 – 100 USD | 20 USD | Founders + Tech + Finance | | Referral cooldown (days) | `S_ref_cooldown` | Minimum distance of days between large referral events to avoid unnatural bursts. | 0 – 7 days | 1 day | Tokenomics + Ops | | Max Tier-1 joins per actor per day | `S_max_t1_per_day` | Limit Tier-1 joins / day per actor before flag review/manual check. | 5 – 30 | 10 | Tokenomics + Ops | | Duplicate device limit | `S_device_dupe` | How many different accounts can share 1 device before it is considered suspicious. | 1 – 5 | 2 | Tech + Risk | | Audit sample rate (%) | `S_audit_pct` | Percentage of transactions/accounts sampled for manual/automated audit. | 1% – 10% | 5% | Risk + Compliance | | Penalty cooling-off (days) | `S_penalty_days` | The length of the suspension/cooling-off period when an abuse case is detected and the reward/ALPHA is temporarily zeroed. | 3 – 30 days | 7 days | Risk + Founders | * Sponsored gas ceilings: * max sponsorship per user per day, * global sponsorship cap per day. * Anti-Sybil parameters (from [TOKENFLOW draft](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=USH0cBRq7yGXLwTmmFDJ\&only=yes\&limit=100)): * referral cooldown, * max Tier-1 joins/day per actor, * device-uniqueness limits. *** ## 6. Scenario Design We will define multiple simulation scenarios. Each scenario will produce metrics for: * sustainability, * fairness, * liquidity, * member experience. ### 6.1 Baseline Scenario * Mirrors AS-IS behaviour as closely as possible. * Purpose: ensure simulation output matches historical patterns. ### 6.2 Conservative Scenario * Lower reward intensity, * stricter caps and windows, * focus on treasury safety and long-term sustainability. ### 6.3 Growth Scenario * Higher reward intensity for selected segments, * more aggressive growth incentives, * monitored for sustainability risks. ### 6.4 Stress-Test Scenarios * Sudden drop in sales (e.g. -30% revenue). * Rapid membership growth (e.g. 2× active members in 12 months). * High cash-out demand (spike in withdrawals). * Changes in behaviour due to new ALPHA sinks. ### 6.5 Scenario Parameter Sets (v0.1) For v0.1, not all parameters will be varied across scenarios.\ We will focus on a **subset of primary “knobs”**: * Reward intensity & pools: `R_global`, `R_pool` * ALPHA caps & sinks: `cap_u`, `cap_g`, `S_target` * Treasury safety: `T_runway`, `T_payoutMax` * Cash-out behaviour: `C_mode`, `C_min_usd`, `C_fee_bps`, `C_win_year`, `C_win_days` * Web3 ops: `G_user_daily_usd`, `G_global_daily_usd` All other parameters will **remain at their default values** for v0.1, unless explicitly stated. #### 6.5.1 Core Scenario Grid | Parameter | Baseline (AS-IS-ish) | Conservative (“Safety-First”) | Growth (“Expansion”) | Notes | | ------------------------- | -------------------------- | ----------------------------- | -------------------- | ----------------------------------------------------- | | `R_global` | 1.0 | 0.85 | 1.15 | Scale all rewards vs AS-IS. | | `R_pool` | 1.0 | 0.9 | 1.1 | Pool share intensity. | | `cap_u` (user ALPHA cap) | 5× P95 | 3× P95 | 7× P95 | Relative to 95th percentile user-month. | | `cap_g` (group ALPHA cap) | 3× P99 | 2× P99 | 4× P99 | Relative to 99th percentile group-month. | | `S_target` (sink target) | 0.60 | 0.50 | 0.70 | % of minted ALPHA expected to be consumed. | | `T_runway` (min months) | 6 | 9 | 6 | Treasury runway safety threshold. | | `T_payoutMax` | 0.90 | 0.80 | 1.00 | Max payout/inflow ratio per month. | | `C_mode` | `ALWAYS_OPEN` | `WINDOWS` | `ALWAYS_OPEN` | Behavioural change to test user vs treasury tradeoff. | | `C_min_usd` | 100 USD | 100 USD | 50 USD | Minimum cash-out amount. | | `C_fee_bps` | 100 bps (1%) | 150 bps (1.5%) | 50 bps (0.5%) | Cash-out fee. | | `C_win_year` | – (unused if ALWAYS\_OPEN) | 4 (quarterly) | – | Pilot window count. | | `C_win_days` | – | 7 | – | Pilot window duration. | | `G_user_daily_usd` | 0.10 USD | 0.07 USD | 0.15 USD | Per-user gas sponsorship cap. | | `G_global_daily_usd` | 20 USD | 20 USD | 40 USD | Global daily gas sponsorship cap. | **Interpretation (for later discussions):** * **Baseline**: very close to existing BGC behaviour, with modest guardrails. * **Conservative**: rewards are dialed down slightly, treasury thresholds are stricter, and cash-out is run under a quarterly window model for stress comparison. * **Growth**: reward intensity is higher, sinks are more active, cash-out is more user-friendly, and gas sponsorship is more generous. These parameter sets are **starting points**.\ They can be refined after the first simulation runs. ### 6.6 External Shocks for Stress-Test Scenarios Stress-test scenarios focus less on changing parameters and more on applying *external shocks* to the Baseline or Conservative parameter sets. For v0.1, we will use the following external shocks: 1. **Revenue Shock (Downturn)** * Overall PC/SP inflow reduced by **30%** over a 6–12 month period. * Goal: observe how quickly treasury runway degrades and whether safety thresholds (`T_runway`, `T_payoutMax`) are violated. 2. **Membership Growth Shock (Expansion)** * Active member count increased by **50%** over 12 months. * PC/SP per member remains the same. * Goal: test whether caps (`cap_u`, `cap_g`) and sponsorship limits (`G_user_daily_usd`, `G_global_daily_usd`) still hold under higher load. 3. **Cash-Out Demand Shock** * Cash-out requests spike by **50–100%** for several consecutive months (e.g. due to external events or campaigns). * Goal: see how payout/inflow ratio and treasury buffers behave when members try to realise rewards more aggressively. 4. **Behavioural Shift Shock (Increased Utility Usage)** * ALPHA sinks become more attractive (e.g. more classes, boosts, CP products). * Sink usage moves from **60% to 80%** of ALPHA minted. * Goal: test whether higher utility consumption improves sustainability or introduces other imbalances. These shocks can be applied on top of: * **Baseline parameters**, to mimic “realistic but stressed” conditions, and * **Conservative parameters**, to see if safety-first settings are sufficient. The results will inform: * how robust the chosen parameter ranges are, * whether additional guardrails are needed, * and what “worst-case” founder decisions should prepare for. *** ## 7. Metrics & Evaluation Criteria Key metrics include: * **Treasury Sustainability** * net outflow vs inflow, * reserve ratio over time, * worst-month drawdown. * **Reward Fairness** * distribution concentration (Reward Gini), * earnings by member tier/segment. * **Member Experience** * average time-to-cash-out, * denial/limitation rate (if windows or caps are applied), * ALPHA utility usage (spend vs hoard). * **System Health** * volatility of obligations, * sensitivity to shocks, * robustness of guardrails. *** ## 8. Simulation Workflow High-level workflow: 1. **Data Ingestion** * Extract and clean 24-month dataset. 2. **Model Preparation** * Map AS-IS rules into simulation logic. 3. **Parameter Set Definition** * Select parameter ranges and default values. 4. **Scenario Execution** * Run baseline, conservative, growth, and stress-test scenarios. 5. **Metric Calculation** * Compute sustainability, fairness, and member experience metrics. 6. **Analysis & Interpretation** * Compare scenarios and identify safe + optimal ranges. 7. **Founder Review** * Present scenario outputs and recommended parameter ranges. *** ## 9. Expected Outputs & Deliverables From this Simulation v0.1, we expect: * **Simulation Report v0.1** * description of scenarios and parameter ranges tested, * tables/graphs of key metrics, * discussion of trade-offs. * **Parameter Recommendations** * suggested ranges for PC/SP → ALPHA, * proposed cash-out models (frequency, thresholds, fees), * proposed caps and guardrails. * **Inputs for:** * [WHITEPAPER v1 (draft)](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=307NXv8YeYMxsWTZaV5z\&only=yes\&limit=100) (final numbers and narrative), * [TOKENFLOW v1 (draft)](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=USH0cBRq7yGXLwTmmFDJ\&only=yes\&limit=100) (final formulas and policy tables), * ALPHA Implementation Blueprint (contract-variable defaults). *** ## 10. Open Questions for Founders A non-exhaustive list of decisions where founder input is needed: * Acceptable range for **cash-out flexibility** vs **treasury safety**. * Appetite for **growth-heavy vs conservative** reward intensities. * Minimum acceptable **reserve buffer**. * Priority between: * user autonomy (always-open cash-out), * system protection (windows, fees, cooling periods). These questions will be refined once the first simulation runs are available. *** ## 11. Versioning & Next Steps * **v0.1 (this doc):** * Define structure, scope, parameters, and scenarios. * **v0.2:** * Integrate real data mapping + first sample outputs. * **v1.0:** * Finalised simulation report for founder decision-making. Next immediate task: * Implement v0.1 across: * data extraction, * parameter tables, * scenario configuration. *** P.S. Read this document freely for information and guidance. Do not redistribute or restate—no quotes, summaries, paraphrases, or derivatives—without prior written permission from [**Prof. NOTA**](https://nota.endhonesa.com/). Sharing the link is allowed. So, share the link, not the text. Do not discuss or re-tell the contents in any form—written, spoken, or recorded—without prior written permission. ***