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

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

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

Caveat

Rows represent month and tier combinations, not individual members.

Appendix Slide B — Scenario Interpretation

No scenario is approved for implementation.

Appendix Slide C — Document Status

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. 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.