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,
• To provide data-backed input for:

  • (final wording and numbers),

  • (final formulas and guards),

This Simulation Doc reads together with:

• (strategic context & execution pillars),

• (AS-IS model),

• ,

• Phase-1 ALPHA Layer simulation, using real BGC × iBLOOMING operational data.

• Modeling of:

  • PC/SP generation and consumption,

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

• BGC transaction logs:

  • PC (Purchase Credit) events,

  • SP (Sales Point) events,

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

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

• Event:

  • PC creation,

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

Examples:

• Total PC, total SP, and their distributions.

• Reward obligations (outstanding, paid, pending).

• Member-level balances and cash-out frequency.

• Simulated ALPHA supply:

This section lists the parameters that will be explored through simulation. Each parameter will have: Name, Symbol, Description, Range, Default, Decision Owner.

• k_PC — PC-to-ALPHA multiplier.

• k_SP — SP-to-ALPHA multiplier.

• Tier-based modifiers for:

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

• ALPHA sinks:

  • classes,

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

• Cash-out frequency:

  • weekly processing (AS-IS),

• Sponsored gas ceilings:

  • max sponsorship per user per day,

  • global sponsorship cap per day.

We will define multiple simulation scenarios.

Each scenario will produce metrics for:

• sustainability,

• fairness,

• liquidity,

• member experience.

• Mirrors AS-IS behaviour as closely as possible.

• Purpose: ensure simulation output matches historical patterns.

• Lower reward intensity,

• stricter caps and windows,

• focus on treasury safety and long-term sustainability.

• Higher reward intensity for selected segments,

• more aggressive growth incentives,

• monitored for sustainability risks.

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

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.

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.

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.

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.

Key metrics include:

• Treasury Sustainability

  • net outflow vs inflow,

  • reserve ratio over time,

High-level workflow:

1. Data Ingestion

   • Extract and clean 24-month dataset.

2. Model Preparation

From this Simulation v0.1, we expect:

• Simulation Report v0.1

  • description of scenarios and parameter ranges tested,

  • tables/graphs of key metrics,

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.

• v0.1 (this doc):

  • Define structure, scope, parameters, and scenarios.

• v0.2:

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