> 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/2025/12/20251209-bgc-iblooming-presentation.md). # BGC X IBLOOMING WORKING PRESENTATION *** ## ✅ I. FULL SLIDE DECK & FULL SCRIPT (6–8 MINUTES) Here we provide the SLIDE PRESENTATION, 6–8 MINUTE SCRIPT, and CLOSING that is very concrete and not floating, all of which have been integrated with: * [UNDERSTANDING Doc](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=4Eh8GomcmSGx85uX6sBg\&only=yes\&limit=100) ✔️ * [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) ✔️ * [WEB3LOGIN Doc](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=wQewHM8gWWhQ0OPtUe6u\&only=yes\&limit=100) ✔️ * [LIVING Doc](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=ijQlNvGkp9UTE2LR2Tjm\&only=yes\&limit=100) ✔️ * And the Bullnium (USD 52K) quotation analysis that was requested. *** ### **Slide 1 — Title** #### BGC × iBLOOMING Integration Progress & Alignment (Phase 1) **Objective Today:** * Clarify system progress (documents, architecture, simulation plan) * Align Phase-1 scope * Review vendor quotation (Bullnium) * Request explicit founder decisions *** #### Script - Speech by Prof. NOTA > Thank you, everyone, for your time today. > > The goal of this session is to give a clear and structured picture of where the BGC × iBLOOMING integration currently stands — not in terms of document completeness, but in terms of **system architecture, alignment, and decision readiness** for Phase 1. > > We will look at four things today: > > * (1) the progress across all documents and flows; > * (2) the architecture and simulation plan; > * (3) the vendor quotation review; > * and (4) the specific decisions needed from founders. *** ### **Slide 2 — Foundations: Documents Overview** #### System groundwork comes from 5 documents: 1. [**UNDERSTANDING Doc**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=4Eh8GomcmSGx85uX6sBg\&only=yes\&limit=100) — Source of truth for: * Affiliate system, PC/SP definitions, SP-based payout, pools, reward mechanics * Business rules that must remain AS-IS 2. [**WHITEPAPER Doc v1 (draft)**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=307NXv8YeYMxsWTZaV5z\&only=yes\&limit=100) — Value-flow principles & ALPHA settlement layer 3. [**TOKENFLOW Doc v1 (draft)**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=USH0cBRq7yGXLwTmmFDJ\&only=yes\&limit=100) — PC/SP → ALPHA conversion, event model, policy parameters 4. [**WEB3LOGIN Doc**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=wQewHM8gWWhQ0OPtUe6u\&only=yes\&limit=100) — Unified identity, wallet provisioning, AA (Smart Account) mapping 5. [**LIVING Doc**](https://baca.endhonesa.com/all-notas-markdowns/~gitbook/pdf?page=ijQlNvGkp9UTE2LR2Tjm\&only=yes\&limit=100) — Strategic Objectives & constraints **Together, these form the system architecture for Phase 1.** *** #### Script - Speech by Prof. NOTA > All the work so far is grounded in **five core documents** that together form the foundation of Phase 1. > > The first is the **UNDERSTANDING Doc**, which defines the operational reality of BGC and iBLOOMING today — how PC is created and consumed, how SP functions, how USD payouts are calculated, and the roles of LTS, RR, GR, GPSP, WEC, Miracle Cash, and CP. These AS-IS rules are essential because they must remain unchanged. > > The second is the **Whitepaper draft**, which establishes the conceptual and compliance framework — including ALPHA as a non-transferable rights unit and the value-flow principles. > > The third is the **Tokenflow draft**, which defines the PC/SP → ALPHA conversion logic, the event model, the append-only flow, and policy parameters. > > The fourth is the **Web3 Login document**, which defines how identity, wallet provisioning, and Smart Account mapping must work. > > And lastly, the **Living Doc**, which contains the strategic objectives and constraints guiding the entire system. > > These five documents collectively define the architecture for Phase 1. *** ### **Slide 3 — What Has Been Completed** #### **High-Level Progress** **1. UNDERSTANDING Doc Consolidation** * Cleaned structural logic for PC, SP, LTS, RR/GR, MC, GPSP, WEC, and CP flows. * Identified AS-IS rules that cannot change. **2. System Architecture (Three-Layer Model)** * Layer 1: BGC Core Business (PC, SP, payouts) * Layer 2: iBLOOMING Identity & Demand Engine * Layer 3: On-Chain Layer (ALPHA, EventHub, AA-based wallet registry) **3. Whitepaper Structure** * Executive summary, problem–solution map, KPIs, compliance frames, fairness metric (Reward Gini). * Core concept: PC/SP → ALPHA rights → spend/access/stake (non-transferable). **4. Tokenflow Skeleton** * Conversion rules * Cash-out windows (KYC, quarterly, 7 days, min $50) * Append-only event model **5. Simulation Plan** * 24-month data * Conversion stress-test * Parameter selection (fairness, sustainability) *** #### Script - Speech by Prof. NOTA > Here is the work that has already been completed. > > First, the **UNDERSTANDING Doc** has been fully consolidated. All structural logic for PC, SP, LTS, RR/GR, GPSP, WEC, and CP flows has been clarified, and the AS-IS rules that cannot be changed are now clearly identified. > > Second, the system has been organized into a **three-layer architecture**: > > * (1) the BGC Core Business Layer, > * (2) the iBLOOMING Identity and Demand Engine, > * and (3) the On-Chain Layer with ALPHA settlement, EventHub, and Smart Accounts. > > Third, the **Whitepaper** has a complete structural foundation — including its executive summary, problem–solution framing, KPIs, compliance narratives, and fairness metrics such as Reward Gini. Its core principle remains: PC/SP converts into ALPHA rights, which are non-transferable and tied to spend/access/stake actions. > > Fourth, the **Tokenflow skeleton** is established: > > * conversion rules, cash-out windows, KYC requirements, quarterly schedules, > * and an append-only event model. > > And fifth, the **simulation plan** is ready. It will use 24 months of historical data to test parameter ranges, validate fairness, and ensure sustainability. *** ### **Slide 4 — Architecture Overview** #### Three Layers * **Layer 1: BGC Core (AS-IS)** * PC = proof of physical product / multi-level selling compliance * SP = base for USD payouts (RR/GR/GPSP/etc.) * **Layer 2: iBLOOMING Demand Engine** * Classes, features, boosts (ALPHA sinks) * CP digital products * Reward multipliers & ecosystem utility * **Layer 3: On-Chain Layer (Phase 1 Minimal)** * ALPHA settlement layer * Non-transferable ERC-20 interface; mint/burn controlled * EventHub: append-only ledger (hashed proofs) * Wallet Registry: maps user → EOA/AA * Sponsored gas limits (≈$0.10/user/day; ≈$20 global/day) This allows **auditability + low friction** without over-complicating the system. *** #### Script - Speech by Prof. NOTA > This is the architecture that emerges from the documents. > > **Layer 1** is the BGC Core — PC as proof of physical product and compliance for multi-level selling, and SP as the base for USD payouts through RR, GR, GPSP, and related mechanics. > > **Layer 2** is the iBLOOMING Demand Engine — which includes classes, features, boosts as ALPHA sinks, digital CP products, and reward multipliers that generate ecosystem utility. > > **Layer 3** is the On-Chain Layer, in a minimal Phase-1 form — a controlled ALPHA settlement contract, non-transferable ERC-20 behavior, an EventHub that records hashed proofs in an append-only format, a Wallet Registry mapping users to EOA or Smart Accounts, and sponsored gas limits that allow smooth UX without over-exposing the system. > > This combination provides **auditability** without adding unnecessary friction. *** ### **Slide 5 — Web3 Login (Implementation View)** #### **From WEB3LOGIN Doc** 1. **Goals** * Unified login for all users (Web2 → Web3) * Automatic wallet provisioning (EOA + optional AA) * Binding identity to EventHub records * Reduce friction for ALPHA usage 2. **Technical Design** * Choose from modern providers (Thirdweb / Privy / Reown) * Minimize custom smart contracts * Use sponsored gas for onboarding and key ALPHA actions * Enforce rate-limits + device rules (anti-Sybil) (Referral cooldown 1 day; max 10 Tier-1 joins/day) This matches the WHITEPAPER and TOKENFLOW documents. *** #### Script - Speech by Prof. NOTA > Next is Web3 Login, which ties the system together at the identity level. > > The goals are simple: > > * a unified login that works for all users, > * automatic wallet provisioning using either EOA or optional Smart Accounts, > * binding user identity to EventHub records, > * and enabling ALPHA actions with minimal friction. > > Technically, the design uses modern providers such as Thirdweb, Privy, or Reown. This reduces the need for custom contracts, keeps onboarding simple, and allows gas sponsorship for key ALPHA actions. > > We also enforce rate-limits and device rules — including anti-Sybil protections such as referral cooldowns and maximum Tier-1 joins per day. > > This design is fully aligned with the Whitepaper and Tokenflow documents. *** ### **Slide 6 — Vendor Quotation Review** #### Bullnium Quotation (USD 52K) * **What Bullnium Proposes** * Custom Web2/Web3 login * Custom Smart Accounts + Paymaster * Smart Contract factory * Identity service * Telemetry system * 6-month timeline * Optional audit +12K 📄 (Based on Bullnium Quotation PDF) * **Assessment** * Price is reasonable **for full custom build**. * **But scope is too heavy** for Phase-1. * Many components duplicate provider features. * 6-month delivery = too slow for our roadmap. * Higher long-term maintenance burden. * **Conclusion for Phase-1**\ Use **modular provider-based integration** → faster (4–6 weeks), safer, lower risk, better aligned with documents. *** #### Script - Speech by Prof. NOTA > We also reviewed the quotation from Bullnium for USD 52,000. > > They propose a full custom build — custom Web2/Web3 login, custom Smart Accounts with Paymaster, a Smart Contract factory, identity services, and telemetry, with a six-month timeline and optional audit. > > The price is reasonable for a full custom build, but the **scope is far larger than what Phase 1 requires**. Many components overlap with what provider-based solutions already offer. And a six-month delivery is too slow for our roadmap. > > So for Phase 1, the modular provider-based approach is **faster** (four to six weeks), **safer**, and more aligned with the documents we have. *** ### **Slide 7 — What Is NOT Final Yet** #### Not final * Needs founder decisions: 1. PC/SP → ALPHA detailed parameters (beyond v1 defaults) 2. Cash-out frequency & thresholds post-pilot 3. Governance: who controls AlphaController 4. Web3 Login provider choice 5. Simulation parameter acceptance 6. Bullnium vs modular vendor decision 7. Priority order of deliverables * Already defined structurally: * All flows * All event models * All policy scaffolding * All compliance guardrails * All architecture layers * All document frameworks *** #### Script - Speech by Prof. NOTA > At this point, the structure across all documents is complete. What is not final are the **parameters and decisions** that must come from the founders. > > These include: > > * the detailed PC/SP → ALPHA parameters, > * cash-out frequency and thresholds after pilot, > * governance for the AlphaController, > * provider selection for Web3 Login, > * simulation parameter acceptance, > * the decision between Bullnium or the modular approach, > * and the order of deliverables. > > What is already defined are the flows, the models, the scaffolding, and the guardrails. What remains is alignment on the choices. *** ### **Slide 8 — Founder Decisions Required (Very Concrete)** #### **Founders Must Decide Now (Phase-1 commitments)** * **Decision 1 — Select Development Approach** * **A: Modular (recommended)** → 4–6 weeks * **B: Bullnium custom build** → 6 months * **Decision 2 — Prioritize Deliverable Order** Choose **one**: * Whitepaper v1 first * Tokenflow v1 first * Simulation output first\ (These three depend on each other — sequence must be fixed.) * **Decision 3 — Cash-Out Policy (Pilot v1)** Approve or adjust: * 4× per year * 7-day window * Min $50 * Fee 1% * Mandatory KYC * **Decision 4 — Web3 Login Provider** * Thirdweb / Privy / Reown (Fully custom implementation only if founders insist.) * **Decision 5 — Governance Holder for AlphaController** * Company? * Technical founder? * Multi-sig? * Hybrid? * **Decision 6 — Approval to Move to Document Finalization** Whitepaper v1 + Tokenflow v1 + Simulation v1. *** #### Script - Speech by Prof. NOTA > To move forward efficiently, there are six concrete decisions that founders need to make now for Phase 1. > > **First**, choose the development approach for Web3 Login: > > * a modular provider approach — which is faster and recommended > * or the Bullnium custom build, which will take six months. > > **Second**, set the priority order of deliverables: > > * Whitepaper v1 first, > * Tokenflow v1 first, > * or Simulation results first. > > These three depend on each other, so the sequence must be fixed. > > **Third**, approve the Pilot v1 cash-out policy — quarterly windows, seven-day duration, minimum fifty dollars, one percent fee, and mandatory KYC — or adjust it. > > **Fourth**, select the provider for Web3 Login: Thirdweb, Privy, or Reown. > > **Fifth**, assign governance of the AlphaController: the company, a technical founder, a multisig, or a hybrid model. > > And **sixth**, give approval to finalize Whitepaper v1, Tokenflow v1, and Simulation v1 after these parameters are aligned. > > These decisions will allow the drafts to evolve into final documents ready for execution. Once alignment is reached, Phase-1 implementation can proceed quickly and cleanly. > > Thank you. *** ## ✅ II. Q & A + NOTES * **Q: Why are documents not final?** > Because parameters require explicit founder decisions. * **Q: Does Bullnium make sense?** > Price yes; scope no. The scope is too big for Phase 1. * **Q: Why modular login?** > 4–6 weeks vs 6 months. Lower risk, aligned with docs. * **Q: Is ALPHA a token?** > ALPHA is a non-transferable rights unit; not for trading. * **Q: Does this change BGC’s USD payouts?** > No — AS-IS rules remain exactly the same. (UNDERSTANDING Doc) * **Q: What’s the biggest blocker now?** > Missing founder decisions on parameters & priority order. * **Note 1:** > “We have structured and synchronized all system documents — UNDERSTANDING, Whitepaper, Tokenflow, Web3 Login, and the simulation plan — so they no longer contradict each other.” * **Note 2:** > “Our work has been architectural and integrative: consolidating logic, designing flows, defining parameters so implementation can proceed without rework.” * **Note 3:** > “We coordinated cross-document consistency so that any provider — internal or external — can implement without ambiguity.” *** ## ✅ **APPENDICES** ### **APPENDIX A — POST-MEETING DEBRIEF (Founder Zoom — Jan 2025)** #### **A. Alignment Achieved** * The founders accepted the **current architecture** as the baseline for Phase 1. * The full document set (Understanding Doc, Whitepaper v1 draft, Tokenflow v1 draft, Web3Login Doc, Living Doc) is now recognized as the **official system foundation**. * Simulation work was acknowledged as a **mandatory first step** before any numerical parameters or formulas can be finalized. * No structural objections were raised; founders engaged only in clarification and refinement. *** #### **B. Responsibilities Clarified** * **Founders** will make the key decisions: parameters, governance, cash-out rules, provider selection, and development approach. * **Prof. NOTA** will continue to serve as system architect: consolidating logic, producing Simulation Doc, aligning cross-document consistency, and preparing the blueprint for implementation. * **Yuku’s engineering team** is a viable executor for the Web3 Login implementation, assuming modular provider approach is chosen. * **Weekly coordination cadence** (proposed by KK) will be established to maintain momentum and avoid delays. *** #### **C. Sensitive Points Raised & Resolved** **1. Cash-Out Windows (User Fairness Concern)** * Concern raised by Mr. Onggy: users may feel restricted if cash-out windows are limited. * Acknowledged as valid from the user point of view. * Resolution: unless founders choose otherwise, the system may **inherit the existing BGC cash-out model**, where rewards accumulate in the e-wallet and users may request cash-out anytime, with weekly processing. **2. ALPHA Token Clarification** * Confirmed: **ALPHA is not a public token**, not tradeable, and not intended for ICO. * ALPHA functions as a **rights unit** inside the BGC × iBLOOMING system and as the basis for simulation. * Public token tracks (e.g., **iBC / iBTC**) are optional and would be handled separately in the future. * Maximum supply, emission logic, and sustainability must come from simulation — not assumptions. *** #### **D. Strategic Observations** * The architecture is now considered **workable and coherent** by all founders. * Your documents are validated as “the system backbone,” shifting your position from contributor to architectural lead. * The founders’ questions demonstrate *adoption*, not hesitation. * The team now shares a unified language for PC/SP, ALPHA, EventHub, Web3 Login, and Tokenflow. * Momentum has shifted toward **execution**, not ideation. *** ### **APPENDIX B — SUMMARY SENT TO KK (Verbatim Copy of Closing Message)** ``` KK, sorry I send this in late night. Anyway, thank you again for coordinating the session earlier. Here is my quick summary and the next steps I will take: 1. The founders have aligned on using the current architecture as the baseline. 2. The Simulation Plan should be completed first, because the outputs will determine the final wording and parameters in the Whitepaper and Tokenflow. 3. Cash-out policy will follow the existing BGC model unless the founders choose otherwise. 4. ALPHA will remain an internal rights token; any public token (iBC/iBTC) can be discussed later as a separate track. 5. For Web3 Login, the modular implementation approach is compatible with the internal engineering team. My immediate work will be: - finalize the Simulation Doc and prepare simulation runs using the 24-month dataset, - outline the dependencies for Whitepaper v1 and Tokenflow finalization, - prepare a clear Next Steps package for next week’s coordination. If you want, we can have a short sync call before the weekly meeting to align details. ``` *** ### **APPENDIX C — NEXT-STEP DOCUMENT (Phase-1 Roadmap)** #### **Overview** This section outlines the concrete next steps required to progress from the current architecture toward Phase-1 implementation. It ensures alignment across founders, engineering, and system design. *** #### **PHASE 1 — SIMULATION DOC (Primary Priority)** **Deliverables** * Simulation Doc v0.1 (structure, objectives, metrics) * Parameter table (initial ranges for PC/SP → ALPHA, windows, caps, sinks) * Conversion pipeline outline (manual first, automated later) * Scenario design (conservative, neutral, aggressive, stress test) * Sensitivity analysis (reward sustainability, supply behavior, operational cost impact) * Preliminary recommendation ranges for founders to review **Why Simulation Comes First** * Determines numerical backbone for Whitepaper v1 * Fixes conversion formulas in Tokenflow * Identifies sustainable emission rates and window strategies * Helps founders finalize governance and operational rules * Prevents guess-based decision-making *** #### **PHASE 2 — WHITEPAPER v1 Finalization** **Contents to be Finalized** * ALPHA rights definition * On-chain vs off-chain boundaries * Compliance & risk framing * EventHub & identity anchor narrative * Token sustainability argument (supported by simulation data) * Phase-1 implementation scope * Optional long-term track: * public token (iBC / iBTC) * listing strategy * treasury considerations **Dependencies** * Must incorporate validated numbers and parameters from simulation. * Requires founder approval on governance decisions. *** #### **PHASE 3 — TOKENFLOW v1 Finalization** **Contents to be Fixed** * PC/SP → ALPHA conversion formulas * Event model (append-only) * Cash-out logic & parameters * Anti-Sybil rules * Gas sponsorship rules * Treasury & reserve logic * Emission guards * Edge-case handling **Dependencies** * Simulation results * Whitepaper v1 framing * Founders’ decisions on windows, thresholds, and governance *** #### **PHASE 4 — TECHNICAL IMPLEMENTATION BLUEPRINT** Companion document to WEB3LOGIN Doc, focused on ALPHA implementation. **Blueprint Contents** * Smart contract architecture * AlphaController * EventHub * Wallet Registry * Treasury mechanics * Non-transferable token model * Gas and sponsorship budget model * Contract ownership & governance (EOA, multisig, hybrid) * On-chain event types & schema * Lifecycle flows for: * earn → record → convert → spend/access → settle * Integration points for engineering team * Security considerations and guardrails **Outcome** This blueprint becomes a **technical handoff** for Yuku’s engineering team or any external provider, ensuring consistent implementation across all layers. *** 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. ***