BGC X IBLOOMING MASTER DOCUMENT

Project Review, Findings, Strategic Transition, and Founder Decisions

Prepared for: BGC × iBLOOMING Founders Founder meeting: On August 2026 Prepared by: Prof. NOTA Technical and simulation contribution: Fabio Kalandra (“Uncle Kal”) Business and operational input: The BGC × iBLOOMING Founders Review period: December 2024 – August 2026 Version: 1.11 — Pre-Meeting Confidentiality: Internal — Founders and Core Team

1. Executive Decision Brief

1.1 Why This Document Exists

The BGC × iBLOOMING Web3 initiative began as an exploration of blockchain identity, loyalty, internal utility, and a possible future public token.

During the following year, the project uncovered a more important reality:

• BGC and iBLOOMING already operate internal value, reward, and entitlement systems;

• the largest recorded cash inflow is concentrated in BGC affiliate-entry transactions;

• iBLOOMING’s direct product economy is much smaller;

• the existing reward system cannot be safely converted into tokens without complete rights, liability, accounting, legal, and tax treatment;

• SIMALPHA is useful as an internal evidence and policy-testing tool, but its first reports do not prove sustainability or token readiness;

• Web3 Login remains independently valuable and ready for engineering implementation;

• the strongest next strategic opportunity is not to create a new speculative financial mechanism, but to build measurable demand for real physical and digital products.

This document closes the original Phase-1 exploration and presents a more disciplined strategic direction.

BGC × iBLOOMING should not tokenize its existing affiliate membership, Purchase Credit, Sales Point, LTS, reward, pool, payout, or deferred obligations.

The present evidence is sufficient to conclude that approving such tokenization now would be premature.

The present evidence is not sufficient to conclude that:

• the existing economic system is financially sustainable;

• current cash-in equals profit;

• reserves are adequate;

• all reward and product obligations are covered;

BGC × iBLOOMING should transition from a reward-led acquisition focus toward a product-led commercial and technology program.

The next program should prioritize:

1. implementation of the approved Web3 Login architecture;

2. independent validation of demand for physical products, digital products, content, education, profiling, and AI-enabled services;

3. product, commerce, retailer, distribution, supply-chain, access, ownership, and trust infrastructure;

The founders are not being asked to approve final token parameters.

They are asked to decide:

1. whether to approve a Product-Led strategic transition;

2. whether to authorize Web3 Login implementation under Yuku and the engineering team;

3. whether to close the old PC/SP-to-ALPHA tokenization track as an automatic roadmap;

This document is not:

• an audited financial statement;

• a forensic accounting report;

• a legal opinion;

• a tax opinion;

BGC operates an affiliate-membership and physical-product-credit system.

A new Affiliate User:

1. pays an entry fee in fiat;

2. receives Purchase Credit;

3. causes LTS to be generated;

4. can trigger reward allocations through the documented network rules.

The final UNDERSTANDING Doc identifies five affiliate levels:

• Pathfinder;

• Voyager;

• Explorer;

• Pioneer;

iBLOOMING is positioned as a digital education, personal-development, content, profiling, and AI-enabled platform.

Its products and programs include concepts such as:

• GiM;

• iLearn;

• iMATRIX;

• Channel Provider content;

Purchase Credit is documented as:

• an internal credit associated with affiliate membership;

• a value used for BGC physical products;

• fixed at a reference of 100 PC = USD 1.

PC must not be casually treated as free cash, profit, a public token, or a right that can be duplicated.

The final UNDERSTANDING Doc records:

• 1 SP as a USD 1 calculation reference;

• LTS equal to 70% of a new affiliate’s entry fee;

• several BGC rewards and pools as percentages of new-join LTS.

The current rules and aggregate data support the conclusion that affiliate-entry cash dominates the recorded economy.

They do not directly measure why each member joined.

The responsible statement is:

The transaction pattern and reward design are consistent with an ecosystem in which the income opportunity is likely a stronger acquisition driver than independent product demand. Member motivation has not yet been directly measured.

The correct test is whether customers buy the same products, at the same prices, without affiliate membership or income opportunity.

Voyage met Mr. Onggy, who introduced iBLOOMING and its AI-enabled education and profiling direction.

Voyage shared experience in Web3 and AI.

The relationship led to a Kuala Lumpur discussion with the five founders.

Voyage:

• explained blockchain, crypto assets, internal utility, ownership, and community mechanisms;

• used iBLOOMING as a case study;

• identified brand, communication, interface, and product-positioning opportunities.

No company-to-company Voyage project was finalized.

• Janet became Creative Lead.

• Prof. NOTA was engaged as blockchain and technology consultant.

The engagement required Prof. NOTA to discover the problem, translate founder expectations, and build the architecture and documentation.

The first proposal focused on:

• Web3 Login;

• unified wallet identity;

• ALPHA as a controlled loyalty simulation;

• user earn, save, and spend behaviour;

The proposal was primarily iBLOOMING-centered and did not yet include a complete BGC economic reconstruction.

The founders responded positively to Web3 Login.

ALPHA was described as a temporary simulation placeholder.

The discussion quickly expanded to:

• a public iBLOOMING token;

• BTC-linked value;

• liquidity;

• staking;

This scope expanded before the full BGC model was understood.

KK explained:

• affiliate membership;

• Purchase Credit;

• Sales Points;

• network rewards;

Prof. NOTA recognized that part of the proposed ALPHA behaviour already existed off-chain.

Yuku raised fundamental questions about:

• token value;

• BTC linkage;

• legal implications;

• product use;

The response at the time was too optimistic. Internal tokenization and future public-token paths were discussed before full rights, reserve, accounting, legal, and tax analysis.

This is now recognized as assumption debt.

Two important specifications were produced.

A final AS-IS reference for:

• user types;

• affiliate levels;

• PC;

• SP;

A detailed architecture for:

• existing credential login;

• Passkey;

• post-login Wallet Setup;

• embedded EOA or connected wallet;

The drafts proposed:

• EventHub;

• AlphaController;

• PC/SP-to-ALPHA conversion;

• non-transferable ALPHA;

These documents made assumptions visible but did not resolve:

• PC product-right substitution;

• SP payout-right substitution;

• double entitlement;

• reserve backing;

An Alignment Call document proposed:

• data mapping;

• simulation;

• Pilot v1;

• owners;

It is an agenda and expected-outcome document, not a complete decision record.

Project records indicate working alignment that:

• simulation should precede final token parameters;

• ALPHA should remain internal and non-public;

• public iBC/iBTC should remain a separate later track;

These are working alignments, not proof that the economics or legal structure were validated.

The document proposed:

• historical-data ingestion;

• PC/SP-to-ALPHA conversion parameters;

• reward intensity;

• sinks;

Its weakness is that it began with token-policy simulation before complete historical accounting reconstruction.

Uncle Kal developed SIMALPHA as a real internal decision console with:

• versioned data snapshots;

• validation;

• scenarios;

• deterministic runs;

Prof. NOTA provided the business architecture and source documents.

Uncle Kal owned the simulator product and implementation decisions.

AI supported implementation but did not own business meaning.

The founders stated that they did not want to spend significant time learning technical reports.

They wanted:

• concrete findings;

• recommendations;

• options;

• decisions.

This changed the required output from “simulator demonstration” to “founder decision interface.”

The available data for the current SIMALPHA scope was cleaned, restructured, and prepared for import.

This phase confirmed the completion of:

• collection of the available data;

• data cleaning;

• restructuring and formatting;

• import preparation;

Reports were produced for:

• Baseline;

• Conservative;

• Growth;

• Stress;

The precise interpretation of this completion is:

The current SIMALPHA data pipeline is complete for preliminary aggregate policy comparison. It is not final economic, accounting, legal, tax, or token evidence.

• founder Web3 education;

• project discovery;

• meeting documentation;

• AS-IS rule reconstruction;

• SIMALPHA product definition;

• application architecture;

• data ingestion;

• validation;

Prof. NOTA is not the sole owner of:

• finance;

• accounting;

• forensic reconciliation;

• legal;

If founders want to proceed into those areas, accountable and qualified owners must be assigned.

SIMALPHA was designed as an internal economic and policy simulator for the BGC × iBLOOMING ecosystem.

Its primary purpose is to take an operating profile derived from available historical or forecast business data and test how different policy configurations affect the circulation, issuance, use, retention, and release of value inside the ecosystem.

The simulation process is:

The parameters tested may include, depending on the scenario:

• ALPHA issuance multipliers;

• reward intensity;

• user and group caps;

• internal-use or sink assumptions;

SIMALPHA therefore does more than demonstrate that data can be imported or that reports can be generated.

It demonstrates how alternative policy configurations behave when applied to a defined BGC × iBLOOMING operating profile.

SIMALPHA can conceptually operate with two different data modes.

Historical data answers:

If these policy and ALPHA rules had been applied to an economic pattern that actually occurred, how would the modeled system have behaved?

This is a historical policy backtest.

A scenario that receives a Ready result means that the tested parameter configuration remains within the simulator's defined thresholds when applied to that historical operating profile.

Forecast data would answer:

If the business achieves this future operating profile, how would the proposed policy configuration behave?

In this mode, the forecast assumptions become operating targets or control assumptions that must later be compared with actual business performance.

The current four selected SIMALPHA reports use imported data rather than an activated Growth Forecast.

A SIMALPHA Ready result should be interpreted as:

The tested policy configuration is compatible with the tested operating profile under the thresholds and rules represented in the current simulation model.

It does not mean that future business conditions are guaranteed to remain identical.

If an approved configuration is later implemented, the operating profile used in the simulation should become a reference benchmark or operating envelope.

Actual performance should then be monitored against material variables such as:

• cash inflow;

• reward generation;

• PC and SP activity;

• internal value usage;

Material deviation from the tested operating envelope should trigger review and, where appropriate, a new SIMALPHA run.

In this way, SIMALPHA can function not only as a pre-implementation simulator but also as an ongoing policy-control and decision-support tool.

The current SIMALPHA compiled dataset contains:

• 236 simulation-ready records;

• 25 monthly periods;

• April 2024–April 2026;

• BGC and iBLOOMING monthly-tier records.

The member_key values in this compiled dataset are synthetic monthly-tier identifiers rather than persistent individual-member identities.

This describes the structure of the compiled SIMALPHA input.

It should not be interpreted as meaning that more granular raw business or member-level source data does not exist.

The raw source material available during the project included multiple datasets and more granular records. The current SIMALPHA dataset represents the portion that was interpreted, transformed, structured, and prepared into a consistent format for the present simulation scope.

Further use of additional raw source tables for institutional accounting, member-level reconstruction, or other purposes would require confirmed data semantics, table relationships, source ownership, and cross-functional validation.

These fields form part of the operating profile used by the current simulation model.

They should be read according to their SIMALPHA data definitions and should not automatically be treated as audited accounting classifications.

The current SIMALPHA work shows that:

• the available business data can be transformed into a consistent simulation-ready operating profile;

• historical BGC and iBLOOMING economic activity can be used as the basis for policy testing;

• policy parameters materially change ALPHA issuance, use, held balances, and modeled cash release;

These are valid outputs of the current simulation scope.

A Ready simulation result is not the same as an automatic company-wide implementation approval.

The current results should not, by themselves, be interpreted as:

• an audited financial statement;

• a certification of company-wide profitability;

• a legal opinion;

• a tax opinion;

SIMALPHA can evaluate model-level sustainability and policy compatibility under the tested conditions.

It should not be described as a standalone certification of every accounting, legal, operational, product, or market dimension of BGC × iBLOOMING.

Where a final implementation decision depends on those additional dimensions, the relevant internal owners and professional functions must validate them.

The current simulation is most directly relevant to an on-chain system that represents substantially the same value flows and economic rights that were included in the simulation.

If ALPHA or another on-chain mechanism is implemented as an internal representation of existing economic activity, its rules should remain within the tested policy boundaries unless a new simulation is performed.

The simulation should not be interpreted as having tested economic behaviours that were not included in the source operating profile.

For example, if the tested business data does not contain:

• open-market trading;

• speculative price discovery;

• public liquidity;

• governance markets;

then the current SIMALPHA results should not be treated as validation of those behaviours.

Any materially different economic function requires a separate model, dataset, scenario, and decision process.

The Baseline scenario is intended to stay close to the existing operating behaviour and provide a reference configuration.

The Conservative scenario applies tighter policy controls and lower value-release intensity.

The Growth scenario applies more permissive or expansion-oriented policy parameters.

The current report should not be interpreted as a forecast of actual future business growth because the selected results use imported data with Growth Forecast disabled.

The original SIMULATION Doc defined Stress testing around external shocks such as:

• revenue decline;

• rapid membership growth;

• cash-out spikes;

• changes in internal-use behaviour.

The current selected Stress report does not apply that full external-shock design.

It primarily applies a more restrictive policy configuration to the same imported operating data.

For the current report set, it is therefore more accurately interpreted as:

Treasury Preservation / Restrictive Policy Scenario

This does not invalidate the result.

It clarifies what the current result actually tests.

A future true stress run may separately apply external shocks to the operating data.

The current reports return Ready for all four selected scenarios within the present simulation thresholds.

This simulator verdict should remain visible.

The correct distinction is:

Ready

Meaning:

The tested configuration passes the thresholds represented in the current model when applied to the tested operating profile.

Pending Founder Decision

Meaning:

A Ready simulator result does not automatically authorize implementation.

Founders must still decide:

• whether the existing economic system should be represented on-chain at all;

• which rights or value flows, if any, should be represented;

• which tested parameter configuration should be considered;

SIMALPHA has successfully completed its current Phase-1 purpose as an internal policy and economic simulation tool.

It has:

• transformed available business data into a simulation-ready operating profile;

• enabled repeatable scenario execution;

• tested alternative policy configurations;

The responsible conclusion is therefore not:

“SIMALPHA failed to prove sustainability.”

The more accurate conclusion is:

SIMALPHA demonstrates model-level policy compatibility and sustainability under the tested operating profile and defined thresholds. Any decision to implement an on-chain representation of those economic flows remains conditional on founder approval, institutional validation of the selected rights and operating conditions, and the scope of the implementation being materially consistent with what was actually simulated.

The existing system must not be tokenized at this stage.

Reasons:

• PC and SP represent different rights;

• conversion may create duplicate entitlements;

• obligations are not fully reconciled;

• public-token backing is unresolved;

Keeping value inside the ecosystem may delay cash outflow.

It does not automatically create external demand, margin, profit, productivity, or reserve.

A token can support ownership, access, auditability, interoperability, and provenance.

It cannot substitute for product quality, pricing, distribution, customer demand, retention, supply chain, or customer support.

Web3 Login has independent value.

It can support:

• unified identity;

• wallet ownership;

• digital receipts;

• product passports;

Its continuation is justified by its product and infrastructure value, not merely because time has already been spent.

BGC × iBLOOMING should measure:

• non-affiliate product buyers;

• affiliate buyers paying new fiat;

• PC redemptions;

• repeat product purchases;

BGC × iBLOOMING should progressively reduce dependence on reward-led acquisition and build a measurable product-led commercial engine. Blockchain and AI should support real products and operations, not become a substitute for product value.

• implement approved Web3 Login;

• create wallet readiness;

• support cross-application identity.

• separate customers from affiliates;

• run product-first campaigns;

• measure conversion, usage, and repeat purchases.

• product catalogue;

• SKU and batch structure;

• inventory;

• wholesale and retail flows;

• authenticity;

• product passports;

• warranty;

• ownership records;

• course and content entitlements;

• subscriptions;

• access passes;

• credentials;

• product recommendation;

• support;

• creator tools;

• product-content matching;

• KPIs;

• decision logs;

• privacy;

• legal gates;

Use conventional technology where it is sufficient. Use blockchain where verifiability, ownership, portability, provenance, interoperability, or multi-party trust creates measurable value. Use AI where it measurably improves decisions, operations, content, or user experience.

Blockchain and AI do not automatically reduce cost or increase security.

Every proposed use must compare:

• conventional database option;

• blockchain option;

• AI-assisted option;

• total cost;

A customer buys a physical product with fiat.

The wallet receives a non-tradable or controlled digital credential containing:

• SKU;

• serial or batch;

• authenticity;

• warranty;

A customer buys GiM, iLearn, a course, or a content package with fiat.

The wallet receives an access credential.

The pilot measures activation, content usage, completion, retention, and support burden.

One purchase may combine:

• physical product;

• digital content;

• onboarding;

• warranty;

This links BGC and iBLOOMING through product utility, not income promises.

Verified retailers or distributors receive credentials showing authorization, product range, territory, validity, and status.

Each pilot must:

• be limited in scope;

• use fiat settlement;

• not promise yield;

• not depend on recruitment;

Any future public token must be separate from the BGC affiliate engine.

It must not:

• be funded through affiliate entry;

• be distributed as recruitment compensation;

• convert PC or SP by default;

• settle existing obligations without explicit treatment;

The apparent interest of members in financial rewards must not be treated as proof that a new financial product is needed.

It does not validate deposits, yield products, lending, staking return, DeFi, DEX, CEX, or fundraising.

Any such business would require separate governance, qualified regulatory advice, licensing analysis, risk management, capital, custody, security, and an independent economic source of yield.

Do not propose a BGC × iBLOOMING DeFi, DEX, CEX, deposit, yield, or fundraising product as the next phase.

Focus on product, commerce, demand, distribution, data, and operations.

Use blockchain only when later justified.

Recommendation: Core strategy.

Implement:

• Web3 Login;

• product passports;

• access credentials;

• retailer credentials;

No public token.

Recommendation: Preferred first implementation path.

Use blockchain for tamper-evident proofs, selected shared events, and multi-party verification.

No token unless separately justified.

Recommendation: Research after data architecture is stable.

Consider only when the right is precisely defined, liability treatment is complete, and conventional credentials are insufficient.

Recommendation: Hold.

Consider only after independent product demand, legal and tax review, market need, rights and reserve design, and separate governance.

Recommendation: Optional research only.

1. Approve or reject Product-Led strategic transition.

2. Authorize Web3 Login implementation.

3. Close the old existing-system tokenization roadmap.

4. Decide public-token status.

Detailed decision wording is provided in the Founder Decision Brief.

• publish meeting resolutions;

• close old LIVING Doc;

• appoint owners;

• begin Web3 Login implementation planning;

• run product-first campaign experiments;

• implement the first identity and access integration;

• create product and commerce data models;

• evaluate pilots;

• publish evidence;

• decide whether to scale;

• create new Product Paper, System Design, or Product Flow only for approved use cases.

No public-token timeline should be established during this period.

BGC × iBLOOMING acknowledges that Phase 1 produced a final AS-IS rules reference, a founder-approved Web3 Login architecture, a working SIMALPHA decision-support application, a prepared aggregate dataset, and preliminary simulation reports.

The founders acknowledge that the current evidence does not support final tokenization of the existing membership, PC, SP, reward, pool, or payout system.

BGC × iBLOOMING therefore resolves to:

1. close the old existing-system tokenization track as an automatic implementation roadmap;

2. proceed with Web3 Login as a separate infrastructure project;

• PC issued, redeemed, outstanding, expired, and fulfillment cost;

• rewards credited, paid, retained, and reinvested;

• pools accrued, funded, distributed, and outstanding;

This work must be institutionally owned. It is not a solo responsibility of Prof. NOTA.

The most important result of this year is not a token.

The result is a clearer understanding of where technology creates value and where it could amplify risk.

BGC × iBLOOMING does not need a new way to make people more interested in putting money into a system. It needs stronger reasons for people to buy, use, trust, and return to its products.

Web3 Login, product ownership, access, authenticity, distribution, and AI-enabled product experiences can support that direction. A public token should remain optional and separate until product demand and institutional readiness are proven.

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.