WEB3 LOGIN HANDOVER NOTE

Web3 Login Implementation Handover Note

Version: 1.0 Date: 5 August 2026 Specification: BGC × iBLOOMING WEB3 LOGIN IMPLEMENTATION — Revision D Specification status: Final and founder-approved, as confirmed by Prof. NOTA Implementation status: Pending Product and architecture owner: Prof. NOTA Technical implementation owner: Yuku Execution team: BGC × iBLOOMING Engineering and DevOps

1. Purpose

This note transfers the Web3 Login project from completed architecture specification into controlled engineering implementation.

It clarifies:

• what has been approved;

• who owns implementation;

• what must be verified before development;

• what is in scope;

• what is not in scope;

• how changes are controlled;

• how the infrastructure supports the Product-Led direction.

Users first authenticate through the existing BGC × iBLOOMING account system.

After successful login, Wallet Setup provides one of two paths:

1. create an embedded or in-app EOA;

2. connect an existing wallet through SIWE.

The system then provisions or maps a Smart Account for cross-application use.

The intended identity relationship is:

Web3 Login remains valuable even if:

• ALPHA is not implemented;

• PC and SP are never tokenized;

• iBC/iBTC is never launched;

• public-token research is stopped.

It can support:

• unified identity;

• wallet-ready product experiences;

• product passports;

• access credentials;

Its continuation is justified by independent infrastructure and product value.

The ability to use the same username and password across applications does not, by itself, prove a single physical credentials database.

Yuku and the engineering team must confirm whether the production architecture uses:

• one database;

• shared authentication service;

• federation;

• replication;

Define:

• canonical user ID;

• BGC user ID;

• iBLOOMING user ID;

• duplicate-account rules;

Decide:

• embedded wallet provider;

• Smart Account provider;

• key custody;

• recovery;

Define:

• development chain;

• testnet;

• production chain;

• RPC provider;

No public-token contract is required for Web3 Login.

Define:

• personal-data boundaries;

• wallet-address storage;

• audit log;

• RBAC;

• login through existing account;

• Passkey support, if approved;

• Wallet Setup after login;

• embedded EOA creation;

• ALPHA issuance;

• PC or SP conversion;

• public iBC/iBTC;

• token trading;

Deliverables:

• current auth diagram;

• identity-source-of-truth decision;

• wallet-provider decision;

• security assumptions;

Deliverables:

• test user login;

• embedded wallet creation;

• existing wallet connection;

• Smart Account provisioning;

Deliverables:

• same identity in BGC and iBLOOMING;

• same expected wallet mapping;

• session consistency;

• duplicate-account handling.

Deliverables:

• recovery;

• merge;

• RBAC;

• logs;

Deliverables:

• limited user cohort;

• support process;

• failure metrics;

• rollback;

After infrastructure acceptance:

• product passport;

• digital access credential;

• receipt;

• retailer credential.

Prof. NOTA does not become the default engineer, DevOps owner, project manager, or support owner merely because he authored the architecture.

The implementation is accepted only when:

• one canonical identity is resolved correctly;

• embedded EOA creation works;

• existing wallet connection works;

• Smart Account provisioning is deterministic or follows an approved replacement design;

A design change is classified as:

• provider-specific API adjustment;

• UI copy;

• logging;

• non-breaking schema extension.

• custody-model change;

• canonical-identity change;

• wallet-per-user policy change;

• recovery-model change;

Material changes require:

• written change request;

• impact analysis;

• Prof. NOTA architecture review;

• Yuku technical approval;

Web3 Login must not silently become a reason to:

• issue ALPHA;

• tokenize PC/SP;

• launch a public token;

• create financial returns;

Wallet readiness is infrastructure.

Every product use case requires a separate approved Pilot Brief or System Design.

The WEB3LOGIN Doc is complete as an architecture specification and approved for implementation.

Implementation, testing, security, rollout, and production operations belong to Yuku and the BGC × iBLOOMING engineering and DevOps teams.

Prof. NOTA will support architectural consistency and Product-Led integration, but implementation ownership must not return to him by default.

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.