Page cover

ALIGNMENT CALL WITH KK

Just a small note before our call on Monday: The 2 years of raw data you sent me last month will be very useful. I haven’t fully cleaned or mapped it yet because I think we need to look at it together

Related docs:

1. Call Objectives

  • Confirm a shared understanding of the current status:

  • Agree on the scope and priorities of a short “Preparation Sprint” while Web3 Login is being implemented (see also WEB3LOGIN Doc).

  • Decide on immediate next steps, owners, and a rough timeline (see also LIVING Doc).


2. Context (Short)

  • Web3 Login implementation is in progress (see also WEB3LOGIN Doc).

  • Last month, KK already shared ~2 years of raw BGC data for analysis (see also LIVING Doc).

  • The raw data has not yet been fully cleaned or mapped, because we still need a joint session to:

    • confirm which columns/fields are “source of truth”, and

    • translate the existing format into the target structure we need for simulation.

  • Instead of waiting passively, we use this time to:

    • Stabilize the story & tokenflow model (see also WHITEPAPER Doc and TOKENFLOW Doc).

    • Finish the data mapping and run a first simulation.

    • Define a realistic and limited Pilot v1.


3. Topics to Cover

3.1 Narrative & Tokenflow Basics

  • Short value proposition of BGC × iBLOOMING (why it exists and for whom).

  • AS-IS → TO-BE:

    • How PC/SP (or equivalent points) map into ALPHA.

    • Append-only event model and hashed evidence.

    • Cash-out windows and KYC boundaries (high-level, non-technical).

See also:

3.2 Data & Simulation

  • Acknowledge that KK has already sent 2 years of raw BGC data.

  • Clarify together:

    • Which parts of the data are complete and reliable enough for a first simulation.

    • Which columns/fields map to our target event structure (earn, redeem, referral, etc.).

  • Agree on a simple target schema for simulation:

    • Minimal fields needed (member ID, timestamp, event type, amount, etc.).

    • How to derive ALPHA balances from the existing records.

  • Define a practical plan:

    • Who helps with data translation/mapping (KK + Prof. NOTA).

    • What is the smallest “slice” of data we use for the first simulation (e.g. 6–12 months).

  • Decide what outputs KK needs from the simulation:

    • Member-level summary (examples).

    • Total liabilities / reward exposure.

    • Edge cases (top earners, very inactive members, etc.).

See also:

3.3 Pilot v1 Shape

  • Target profile and approximate number of participants.

  • Pilot duration.

  • What participants can earn/redeem and under what conditions.

  • Operational roles:

    • Who handles support and questions.

    • Who reviews KYC/cash-out issues.

    • Who is allowed to adjust parameters during the pilot.

See also:

  • KK’s view on:

    • ToS and disclaimers (non-investment, no guaranteed returns, etc.).

    • Basic privacy/data statement.

    • Handling suspicious or abusive behavior (freeze, block, etc.).

See also:


4. Expected Outcomes

By the end of the call, we aim to have:

  • Agreement on the Preparation Sprint structure and workstreams.

  • A list of data requests and a person responsible for gathering them.

  • Clarity on:

    • What we can already move forward with (before Web3 Login is ready).

    • When and how to involve Yuku in a focused tech session.

See also:


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