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.
Objective Today:
Clarify system progress (documents, architecture, simulation plan)
Align Phase-1 scope
Review vendor quotation (Bullnium)
Request explicit founder decisions
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.
Together, these form the system architecture for Phase 1.
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.
1. UNDERSTANDING Doc Consolidation
Cleaned structural logic for PC, SP, LTS, RR/GR, MC, GPSP, WEC, and CP flows.
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)
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,
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.
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.
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
This matches the WHITEPAPER and TOKENFLOW documents.
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,
What Bullnium Proposes
Custom Web2/Web3 login
Custom Smart Accounts + Paymaster
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.
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,
Decision 1 — Select Development Approach
A: Modular (recommended) → 4–6 weeks
B: Bullnium custom build → 6 months
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:
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.
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.
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.
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.
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.
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.
Identifies sustainable emission rates and window strategies
Helps founders finalize governance and operational rules
Contents to be Finalized
ALPHA rights definition
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.
Contents to be Fixed
PC/SP → ALPHA conversion formulas
Event model (append-only)
Cash-out logic & parameters
Anti-Sybil rules
Dependencies
Simulation results
Whitepaper v1 framing
Founders’ decisions on windows, thresholds, and governance
Companion document to WEB3LOGIN Doc, focused on ALPHA implementation.
Blueprint Contents
Smart contract architecture
AlphaController
EventHub
Wallet Registry
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.
(3) the vendor quotation review;
and (4) the specific decisions needed from founders.
These five documents collectively define the architecture for Phase 1.
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.
And fifth, the simulation plan is ready. It will use 24 months of historical data to test parameter ranges, validate fairness, and ensure sustainability.
Sponsored gas limits (≈$0.10/user/day; ≈$20 global/day)
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.
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.
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
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.
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.
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.
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.”
No structural objections were raised; founders engaged only in clarification and refinement.
Weekly coordination cadence (proposed by KK) will be established to maintain momentum and avoid delays.
Maximum supply, emission logic, and sustainability must come from simulation — not assumptions.
The team now shares a unified language for PC/SP, ALPHA, EventHub, Web3 Login, and Tokenflow.
Momentum has shifted toward execution, not ideation.
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.