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,

This Simulation Doc reads together with:

• (strategic context & execution pillars),

• (AS-IS model),

• ,

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,

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.).

3. Data Sources & Assumptions

3.1 Data Sources (24-Month Window)

• BGC transaction logs:

  • PC (Purchase Credit) events,

  • SP (Sales Point) events,

3.2 Key Assumptions

• Data is sufficiently clean to support scenario modeling (minor anomalies will be noted).

• AS-IS reward rules from are taken as baseline behaviour.

• No new external shocks (e.g. regulation bans) are assumed in v0.1 scenarios.

4. Simulation Model Overview

4.1 Entities

• Member: an individual with PC/SP history, wallet balance, and cash-out actions.

• Event:

  • PC creation,

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.

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

• k_PC — PC-to-ALPHA multiplier.

• k_SP — SP-to-ALPHA multiplier.

• Tier-based modifiers for:

5.2 Reward & Treasury Parameters

5.2.1 Parameter Table — Reward & Treasury

• Reward share splits (RR/GR/GPSP/etc., as represented in ALPHA).

• ALPHA sinks:

  • classes,

5.3 Cash-Out Parameters

5.3.1 Parameter Table — Cash-Out

• Minimum cash-out amount (e.g. 50–100 USD equivalent).

• Cash-out frequency:

  • weekly processing (AS-IS),

5.4 Web3-Related Operational Parameters (Phase-1 Touchpoints)

5.4.1 Parameter Table — Web3 Ops (Gas & Anti-Sybil)

• Sponsored gas ceilings:

  • max sponsorship per user per day,

  • global sponsorship cap per day.

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).

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

All other parameters will remain at their default values for v0.1, unless explicitly stated.

6.5.1 Core Scenario Grid

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

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,

8. Simulation Workflow

High-level workflow:

1. Data Ingestion

   • Extract and clean 24-month dataset.

2. Model Preparation

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,

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.

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:

Next immediate task:

• Implement v0.1 across:

  • data extraction,

  • parameter tables,

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 . 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.