We don't belong in your reality, your real life. In your reality, your real life, you can merely meet our avatars in any version. So, stay alert and beware of scams!
Authors: Prof. NOTA (proposal), Yuku (technical owner), BGC & iBLOOMING engineering/DevOps
Audience: BGC & iBLOOMING founders, engineers, QA, DevOps, PMs
Status: Draft for implementation sign‑off
Last updated: 2025‑09‑29 (Asia/Jakarta)
1) Executive Summary
We propose to ship Web3 Login first (October) while the team finalizes the Whitepaper & Tokenomics. This delivers a visible, low‑risk foundation for the ecosystem:
Unified identity across BGC Web, iBLOOMING Web, and iBLOOMING Mobile via one EOA (Externally Owned Account) and one Smart Account (Account Abstraction/AA) per user per chain.
Bridges Web2 ↔ Web3: users can start with email/phone/passkey or existing BGC/iB credentials and seamlessly obtain a self‑custodial wallet; Web3‑native users can connect existing wallets.
Faster analytics: reliable, on‑chain‑addressed telemetry for behavior simulations (Alpha Coin → later iBC/iBTC).
Partner signal: live working login across apps shows momentum while tokenomics is being finalized.
Quick win with high user impact.
Necessary base layer for identity‑keyed rewards & future settlements.
Decoupled scope (can be executed by a small pod; minimal cross‑team contention).
Launch of production token contracts, DEX/CEX listings, or final economic parameters.
Multi‑chain rollout (focus on a single chain first; propose Base testnet → mainnet).
Single EOA per user (master identity).
One Smart Account (AA) per user per chain, deterministic (CREATE2) from the EOA + salt so the AA address stays the same across BGC & iBLOOMING.
Identity Bridge Service maps: identity_id ⇄ EOA ⇄ AA ⇄ bgc_user_id ⇄ ib_user_id.
In‑scope
A single Login entry with six options:
(1) Login with BGC
(2) Login with iBLOOMING
(3) Login with Email (OTP)
(4) Login with Phone (OTP)
(5) Login with Passkey (biometric)
(6) Login with Web3 Wallet (Connect Wallet)
Automatic wallet provisioning & upgrade:
Options 1‑5
Out‑of‑scope (defer to later sprints)
Gas sponsorship in production (can pilot on staging).
OAuth socials (Google/Apple/etc.) unless trivial to include.
Mobile deep‑linking polish (basic flows supported; advanced UX later).
Soft launch on staging; internal dogfooding across both apps.
Email/WA campaign: “Bind your wallet” (3 clicks).
Progressive feature flag: new signups auto‑provision wallets; after ≥95% existing users are bound, auto‑create BGC+iB accounts for new identities.
Duplicate identities due to race conditions → enforce DB uniqueness + retry/merge workflow.
OTP deliverability → fallback channel (email↔SMS), resend with backoff.
Mobile deep‑link quirks → use universal links + WalletConnect v2; provide QR fallback.
Use the ConnectButton (React Native) or the HTTP API to support Email/Phone/Passkey + WalletConnect.
Keep the same accountAbstraction settings; reuse Identity Bridge endpoints.
A founder‑friendly glossary of terms and acronyms used in this plan. Short, plain‑English definitions come first; technical notes follow in parentheses when helpful.
EOA (Externally Owned Account): A standard crypto wallet controlled by a private key (e.g., MetaMask address). (EVM concept.)
Smart Account / Smart Wallet: A programmable wallet implemented as a smart contract. In our plan it’s created from the user’s EOA and follows ERC‑4337 rules.
Account Abstraction (AA): A model (EIP‑4337) that makes smart accounts act like normal wallets but with extra powers (gas sponsorship, batching, policies).
Web2 Login: Traditional login via existing BGC/iB accounts, email+OTP, phone+OTP, or passkey.
Web3 Login: Authentication using a crypto wallet (EOA) and SIWE.
SIWE (Sign‑In With Ethereum / EIP‑4361): A standard where users sign a human‑readable message with their wallet to prove control of an address (no transaction required).
No Plaintext Private Keys: Private keys are never stored or transmitted as raw text. In‑App wallets use secure enclaves/MPC/OS keystores.
Nonce: A unique value used once to prevent replay (exists in SIWE and in on‑chain transactions; context differs).
Tokenomics: The economic design of a token (supply, emissions, rewards). Final parameters are out‑of‑scope for October.
DEX/CEX: Decentralized/Centralized Exchanges where tokens can be traded. Listings are out‑of‑scope for October.
Airdrop / Faucet: Token distribution mechanisms; faucets usually provide small testnet funds for testing.
EVM (Ethereum Virtual Machine): The execution environment for smart contracts used by Ethereum and many L2s (including Base).
Base: An Ethereum Layer‑2 (OP Stack) we target for staging (testnet) and production (mainnet).
Gas / Gas Price / Gwei: Computational fee paid to execute transactions. Gas sponsorship = someone else pays.
Identity Bridge Service: A small service (our component) that maps identity_id ⇄ EOA ⇄ AA ⇄ bgc_user_id ⇄ ib_user_id, exposes /identity, /account/link, /identity/merge, etc.
JWT (JSON Web Token): A signed token for session/auth between services (header.payload.signature).
Deep Link / Universal Link (iOS) / App Link (Android): Mechanisms to open an app to a specific screen from a URL.
Wallet Deep Linking: Opening a wallet app from a dApp and returning the user after approval.
QR Fallback: Displaying a QR code users can scan with their wallet if deep linking fails.
Telemetry: Operational data (success/error rates, latency) used for monitoring.
Behavior Analytics: Measuring user actions tied to on‑chain identity (for simulations like Alpha Coin → later iBC/iBTC).
Anomaly Detection: Automated alerts for suspicious patterns (e.g., unusual merges or link spikes).
Sign‑off: Formal approval gate before production release (scope, security, QA, monitoring, rollback ready).
Green‑light rule: proceed to production only when all five items are checked ✅.
Owner mapping: (1) Founders/PM, (2) Security/Eng, (3) QA/DevOps, (4) DevOps/Eng Mgmt, (5) SRE/DevOps.
End of document.
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.
Standards‑first: SIWE (EIP‑4361) for wallet authentication; ERC‑4337 for account abstraction.
Security by design: no plaintext private keys; passkeys/OTP; audit trails for link/merge.
Post‑launch monitoring; incident playbook; weekly audit of merges.
Gas spikes on mainnet → keep Paymaster off in prod initially; batch AA deployments; pre‑fund only when needed.
User confusion → clear copy in UI: “You will get a self‑custodial wallet; keep access factors safe.”
EntryPoint: The on‑chain contract used by ERC‑4337 to validate and execute UserOperations (the “router” for smart account actions).
Bundler: A service that collects UserOperations from many users and submits them to the EntryPoint in one transaction.
Paymaster: A component that sponsors transaction gas on behalf of users (enables “gasless” UX) with rules/limits.
Deterministic Deployment / CREATE2: A method to pre‑compute a smart contract address before it is deployed (address determined by salt + bytecode + deployer). Used so a user’s smart account address stays consistent across apps.
Counterfactual Address: A contract address computed before deployment (via CREATE2); it becomes real when deployed.
Chain / Chain ID: A specific blockchain network (e.g., Base mainnet has a numeric chain ID). Apps must explicitly select the chain.
Passkey (WebAuthn): Passwordless sign‑in using device biometrics/secure hardware (Face/Touch ID). In our setup, passkeys can secure an In‑App Wallet.
OTP (One‑Time Password): A one‑time code sent by email/SMS for verifying ownership of a channel during login or linking.
In‑App (Embedded) Wallet: A non‑custodial wallet generated and secured via SDK (e.g., with passkey/OTP). Users don’t paste private keys; recovery relies on chosen factors (e.g., passkey, email).
WalletConnect / EIP‑6963: Protocols enabling dApp ↔ wallet connections across browsers/devices; EIP‑6963 improves wallet discovery in browsers.
Link (Account Linking): Attaching an app account (BGC/iB) to a single on‑chain identity (EOA/Smart Account). Requires proofs (OTP/SIWE).
Merge (Identity Merge): Combining two identities into one (e.g., when duplicate records exist). Requires stronger proofs and admin approval.
Replay Attack: An attacker reuses a previously valid message; prevented by unique nonces and expiration windows.
PII (Personally Identifiable Information): Data that can identify a person (email, phone, etc.). We minimize and protect it.
RBAC (Role‑Based Access Control): Access permissions based on user roles (e.g., Admin, SecurityOps).
KYC/AML: Know‑Your‑Customer / Anti‑Money‑Laundering checks. Out‑of‑scope for October beyond basic OTP verification.
Phishing: Trick users to reveal secrets; we never ask users to paste private keys in app UIs.
Audit Trail: An immutable record of critical actions (link/merge), including who/what/when/how, for forensics and accountability.
WORM Storage: Write‑Once‑Read‑Many log storage to ensure logs cannot be tampered with post‑write.
Settlement: Converting points/rights into transferable value (often requires final token design; not in October scope).
Address / Checksum Address: Public identifier of a wallet/contract; checksum casing helps detect typos.
ABI (Application Binary Interface): The interface (function/event signatures) used to call smart contracts.
Event Logs: On‑chain records emitted by contracts (used for indexing and analytics).
Hash: A fixed‑length fingerprint of data (used for integrity, signatures, addresses, logs).
OAuth 2.0 / OIDC: Web auth standards used by many platforms; optional for later social logins (Google/Apple).
Twelve‑Factor Config: A practice of storing configuration in environment variables (not in code), enabling portable deployments.
Feature Flags: Switches to enable/disable features at runtime without redeploying; used for safe launches and rollbacks.
Rollback Plan: A predefined, step‑by‑step procedure to revert a release safely.
Idempotency: Designing APIs so repeating the same request doesn’t produce duplicate effects (important for wallet provisioning/linking).
Rate Limiting / 429: Limits requests per time window to protect from abuse; HTTP 429 is “Too Many Requests.”
Observability: The trio of metrics, logs, traces used to monitor health and diagnose issues.
CI/CD: Continuous Integration/Continuous Delivery pipelines for automated build/test/deploy.
E2E Tests: End‑to‑end tests simulating real user flows across systems (e.g., six login paths → EOA → AA → link accounts).
Acceptance: all six login paths pass on staging/testnet; EOA→AA works; link/merge flows pass; audit logs recorded; E2E suite green; basic load test acceptable.
Artifacts: QA report (pass rates), evidence of AA on testnet, load test summary.
Production feature flags & rollback plan
Acceptance: feature flags exist per capability (Connect UI, provisioning, link/merge); defaults documented; rollback playbook verified in rehearsal; backups/restores tested.
Artifacts: flag registry & defaults, rollback playbook, post‑rollback checklist.
Post‑launch monitoring dashboards
Acceptance: dashboards & alerts live for: login success/error, AA provisioning latency/failure, OTP delivery, SIWE errors, duplicate‑identity attempts; on‑call rota confirmed.
Artifacts: links to Grafana/ELK dashboards, alert thresholds, escalation policy.