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 architectur
✅ 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:
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)
Review vendor quotation (Bullnium)
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;
Slide 2 — Foundations: Documents Overview
System groundwork comes from 5 documents:
— Source of truth for:
Affiliate system, PC/SP definitions, SP-based payout, pools, reward mechanics
Business rules that must remain AS-IS
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.
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
Cash-out windows (KYC, quarterly, 7 days, min $50)
5. Simulation Plan
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,
Slide 4 — Architecture Overview
Layer 1: BGC Core (AS-IS)
PC = proof of physical product / multi-level selling compliance
SP = base for USD payouts (RR/GR/GPSP/etc.)
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
Unified login for all users (Web2 → Web3)
Automatic wallet provisioning (EOA + optional AA)
Binding identity to EventHub records
Choose from modern providers (Thirdweb / Privy / Reown)
Minimize custom smart contracts
Use sponsored gas for onboarding and key ALPHA actions
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,
Slide 6 — Vendor Quotation Review
Bullnium Quotation (USD 52K)
What Bullnium Proposes
Custom Smart Accounts + Paymaster
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
Needs founder decisions:
PC/SP → ALPHA detailed parameters (beyond v1 defaults)
Cash-out frequency & thresholds post-pilot
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,
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
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:
✅ 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.
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.
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.
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.
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.
APPENDIX B — SUMMARY SENT TO KK (Verbatim Copy of Closing Message)
APPENDIX C — NEXT-STEP DOCUMENT (Phase-1 Roadmap)
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)
Why Simulation Comes First
Determines numerical backbone for Whitepaper v1
Fixes conversion formulas in Tokenflow
Identifies sustainable emission rates and window strategies
PHASE 2 — WHITEPAPER v1 Finalization
Contents to be Finalized
On-chain vs off-chain boundaries
Compliance & risk framing
EventHub & identity anchor narrative
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
Dependencies
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
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 . 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.