BGC X IBLOOMING WORKING PRESENTATION
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:
LIVING Doc ✔️
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:
UNDERSTANDING Doc — Source of truth for:
Affiliate system, PC/SP definitions, SP-based payout, pools, reward mechanics
Business rules that must remain AS-IS
WHITEPAPER Doc v1 (draft) — Value-flow principles & ALPHA settlement layer
TOKENFLOW Doc v1 (draft) — PC/SP → ALPHA conversion, event model, policy parameters
WEB3LOGIN Doc — Unified identity, wallet provisioning, AA (Smart Account) mapping
LIVING Doc — 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
Goals
Unified login for all users (Web2 → Web3)
Automatic wallet provisioning (EOA + optional AA)
Binding identity to EventHub records
Reduce friction for ALPHA usage
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:
PC/SP → ALPHA detailed parameters (beyond v1 defaults)
Cash-out frequency & thresholds post-pilot
Governance: who controls AlphaController
Web3 Login provider choice
Simulation parameter acceptance
Bullnium vs modular vendor decision
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)
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. 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.
Last updated