> 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/2026/08/20260802-02-founder-presentation-5-august-2026.md). # BGC X IBLOOMING FOUNDER PRESENTATION ## Phase-1 Closure and Product-Led Strategic Transition **Date:** 5 August 2026\ **Presenter:** Prof. NOTA\ **Recommended duration:** 20 minutes presentation + 40–60 minutes decision discussion\ **Status:** Final pre-meeting draft *** ## Slide 1 — Why We Are Here ### On Slide #### BGC × iBLOOMING **Phase-1 Review, Findings, and Founder Decisions** Today we need to decide: 1. what Phase 1 has completed; 2. what the evidence supports; 3. what should stop; 4. what should continue; 5. what the next program should become. ### Speaker Notes Thank you for the opportunity to present the full project journey. This meeting is not intended to ask you to study every technical report or become experts in blockchain. My responsibility today is to translate one year of documents, architecture, data preparation, simulation, and findings into clear business decisions. The most important question is no longer: > “How do we launch a token?” The more responsible question is: > “What technology direction can increase real product demand and business value without duplicating obligations or creating a new speculative burden?” *** ## Slide 2 — How the Project Evolved ### On Slide ``` Web3 exploration → Web3 Login and ALPHA concept → discovery of the BGC economic model → UNDERSTANDING and WEB3LOGIN specifications → Whitepaper and Tokenflow hypotheses → simulation-first correction → SIMALPHA → founder decision phase ``` ### Speaker Notes The original proposal was centered on iBLOOMING, Web3 Login, and a controlled loyalty simulation. After KK explained BGC’s Purchase Credit, Sales Point, LTS, rewards, and pools, we learned that the ecosystem already had an internal value system. We therefore moved from creating a token concept to reconstructing the real operating system. In December 2025, simulation became the required first step. From March 2026, Uncle Kal built SIMALPHA as a real internal decision console. The project is now at the point where documents and software must be converted into founder decisions. *** ## Slide 3 — What Has Been Completed ### On Slide #### Final or Completed * UNDERSTANDING Doc — AS-IS business and reward rules * WEB3LOGIN Doc — approved architecture specification * Whitepaper and Tokenflow — completed as draft hypotheses * SIMULATION Doc v0.1 * SIMALPHA working MVP * data cleaning and import pipeline * 25-month aggregate dataset * four scenario reports * comparison report and founder glossary #### Still Pending * Web3 Login engineering implementation * final economic reconciliation * legal and tax validation * any token implementation ### Speaker Notes It is important to distinguish specification from implementation. The Web3 Login architecture is complete and approved. Its implementation remains the responsibility of Yuku and the engineering team. The Whitepaper and Tokenflow drafts are useful historical and design artifacts, but they are not approved implementation plans. SIMALPHA works as an internal simulation and reporting application. The reports exist, but their evidence is preliminary. *** ## Slide 4 — The Most Important Economic Finding ### On Slide #### Two Different Economic Engines | BGC | iBLOOMING | | ------------------------------ | ------------------------------------------- | | Affiliate-entry driven | Product-transaction driven | | New join creates LTS | Product sale creates revenue | | Rewards linked to new-join LTS | Rewards allocated from product transactions | | Recorded cash-in: ≈ $4.034M | Recorded cash-in: ≈ $21.1K | #### Key Message > The ecosystem is economically dominated by affiliate-entry transactions, while direct product revenue remains very small. ### Speaker Notes The data does not directly prove why every member joined. However, the reward design and transaction pattern are consistent with an ecosystem where the income opportunity is likely a stronger acquisition driver than independent product demand. The correct next test is whether people buy the same products at the same price without an affiliate-income opportunity. *** ## Slide 5 — What SIMALPHA Proves and Does Not Prove ### On Slide #### SIMALPHA Proves * data can be imported; * policy scenarios can be run; * results are deterministic; * issuance and cash-release rules change outputs; * reports can support structured discussion. #### SIMALPHA Does Not Yet Prove * profit; * reserve safety; * sustainability; * member-level fairness; * product liability coverage; * tax reduction; * public-token readiness. ### Speaker Notes SIMALPHA is a successful working MVP. However, its current dataset contains monthly-tier aggregate records, not persistent individual member histories. The first reports use incomplete accounting and liability fields. Therefore, we should not use the current reports to lock token parameters or claim that a scenario is financially safe for implementation. *** ## Slide 6 — Why We Should Not Tokenize the Existing System ### On Slide #### Existing-System Tokenization Risks * PC represents a product entitlement. * SP represents a reward or payout basis. * Converting both may create duplicate rights. * Pool and payout obligations are not fully reconciled. * Product cost and reserve are incomplete. * Public-token backing and redemption are unresolved. * Tokenization may automate the current risk without creating productive demand. #### Recommendation > Do not tokenize membership, PC, SP, LTS, rewards, pools, or payouts. ### Speaker Notes This is not a statement that blockchain has failed. It means blockchain should not be used to turn unclear obligations into programmable obligations. Any further financial validation requires Finance, Accounting, Operations, Legal, Tax, Data, and Engineering resources—not Prof. NOTA alone. *** ## Slide 7 — The New Strategic Direction ### On Slide ## Product-Led Systems Transformation Shift from: > reward-led acquisition toward: > measurable product demand Focus: * physical products; * digital products and content; * commerce; * supply chain; * retailer and distributor systems; * product access; * authenticity; * ownership; * customer usage and repeat purchase. ### Speaker Notes The strongest opportunity discovered through this project is Product-Led transformation. Marketing should progressively explain: * what the product does; * who needs it; * why it is worth the price; * how it is delivered; * why the customer uses it again. Product sales and usage should be measured separately from affiliate recruitment. This creates a healthier role for blockchain and AI: supporting products and operations instead of creating a new speculation mechanism. *** ## Slide 8 — What Continues Immediately ### On Slide ### 1. Web3 Login * final and approved specification; * implementation owner: Yuku and engineering; * Prof. NOTA: architecture and integration support. ### 2. Product-Demand Baseline * non-affiliate buyers; * direct fiat product sales; * repeat purchase; * content usage; * subscription retention; * product margin. ### 3. Small Web3 Product Pilots * physical-product passport; * digital-access pass; * product-content bundle; * retailer or distributor credential. ### Speaker Notes Web3 Login remains valuable even without a public token. It can create wallet-ready identities for: * digital receipts; * product passports; * access credentials; * ownership records; * retailer verification. The first pilots should be limited, non-tradable, and paid in fiat. They should not promise money, yield, or price appreciation. *** ## Slide 9 — Boundaries ### On Slide #### Public Token * optional research only; * separate from BGC affiliate rewards; * no PC/SP default conversion; * no guaranteed redemption; * no yield or price promise; * no use of new buyers to pay existing obligations. #### Financial Products This program will not create: * deposits; * promised yield; * DeFi; * DEX; * CEX; * fundraising through the affiliate network. ### Speaker Notes A strong appetite for financial return is not proof that the company should build a financial product. A public token or financial-services business would require different governance, licensing, capital, security, compliance, and risk-management capability. That should not be treated as the automatic next step of this project. *** ## Slide 10 — Decisions Required Today ### On Slide Founders are asked to decide: 1. approve Product-Led strategic transition; 2. approve Web3 Login implementation; 3. close old existing-system tokenization drafts as active plans; 4. keep public token as separate research only; 5. choose one physical and one digital product pilot; 6. separate product metrics from affiliate metrics; 7. assign owners and resources; 8. approve the financial-product boundary; 9. confirm Prof. NOTA’s Product and Web3 Transformation role; 10. authorize creation of the 2026–2027 Product-Led Systems Program. ### Closing Script Phase 1 has created real value: * a documented operating model; * an approved identity architecture; * a functioning simulator; * a prepared dataset; * and a clearer understanding of where technology is useful and where it may amplify risk. The responsible conclusion is not that tokenization has failed. The conclusion is: > We should use blockchain and AI where they strengthen products, ownership, access, commerce, distribution, and trust—and keep speculation and financial-return promises outside this program. *** ## Appendix Slide A — SIMALPHA Data Snapshot | Metric | Combined | | ------------------------ | --------------------: | | Period | April 2024–April 2026 | | Aggregate rows | 236 | | Cash in | $4,055,155.00 | | Recognized-revenue field | $4,040,373.10 | | Direct/global reward | $412,815.06 | | Pool reward | $509,239.09 | | Historical cash-out | $572,221.19 | | Internal credit spend | $567,234.00 | #### Caveat Rows represent month and tier combinations, not individual members. *** ## Appendix Slide B — Scenario Interpretation | Scenario | Correct Interpretation | | ------------ | ------------------------------------------ | | Baseline | Initial policy reference | | Conservative | Reduced issuance and cash release | | Growth | Increased issuance and cash release | | Stress | Treasury Preservation / Restrictive Policy | No scenario is approved for implementation. *** ## Appendix Slide C — Document Status | Document | Status | | --------------- | ------------------------------------------ | | UNDERSTANDING | Final | | WEB3LOGIN | Final and approved; implementation pending | | Whitepaper | Archived draft | | Tokenflow | Archived draft | | SIMULATION Doc | Archived v0.1 | | SIMALPHA | Working MVP | | Reports | Preliminary evidence | | LIVING Doc | Close after transition update | | Master Document | Active founder decision source | *** ## Appendix Slide D — Difficult Questions ### “Does this mean the last year was wasted?” No. The year produced specifications, software, evidence, and a more responsible direction. ### “Why not launch a simple token anyway?” Because tradability creates legal, market, accounting, liquidity, and reputational risks even when no price increase is promised. ### “Why continue Web3 Login?” Because identity, wallet readiness, credentials, ownership, and access remain useful independently of tokenization. ### “Do we need more data?” Not for deciding to stop existing-system tokenization. More targeted evidence is needed only if founders want to approve financial or token implementation. ### “Why Product-Led?” Because the present ecosystem needs stronger independent product demand, not a new mechanism for attracting money. *** 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. ***