Skip to main content

Bluwhale

Bluwhale — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Bluwhale — a decentralized personalization protocol: it builds knowledge graph/embedding profiles of wallets and gives dApps/agents a layer for targeting/segmentation; token: BLUAI (BEP‑20, BNB Chain).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: an “intelligence layer” for Web3: user/wallet profiles and personalization for dApps.
  • Who it’s for: projects/dApps that need user segments and communications; users who monetize access to their data/profile.
  • Why onchain/token: onchain is used for accounting/incentives and onchain communications; BLUAI is the ecosystem’s utility token (payments/incentives/governance, per the whitepaper).

How it works (very briefly)

  1. The user does: connects a wallet/profile and (per the project’s model) confirms/verifies links and preferences.
  2. The system does: aggregates onchain traces and builds profiles/segments (knowledge graph + embedding space) so that dApps can perform personalization.
  3. The user gets: an improved experience in dApps and/or rewards for participation; projects get more precise targeting and communication channels.
  4. Where the blockchain is: onchain activity is used as raw material for profiling; some functions involve onchain messages/access accounting/payments.
  5. Token role (if any): BLUAI is described as a currency and a utility/governance token used in the platform economy (including messaging/incentives).

Quick links: AI thesis fit

Project passport

Field Value
Project name Bluwhale
Also known as (aliases) Bluwhale AI; BLUAI
Logo (logo) ../assets/152_bluwhale_logo.svg
Token symbol (ticker) BLUAI
Category AI/Data | Infra
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) 2024 (the whitepaper is dated 2024‑03‑20)
Project status (status) active
Token (standard) BEP-20
Token contract 0xed9Ae3DEF8d6F052971Bb8b6d1975FF267Cf9aaD
Token model (token_type) utility (incentives + governance)
Max supply 10,000,000,000 BLUAI
Issuance max supply (per BscScan)
Tokenomics (tokenomics, brief) Use‑to‑earn economy and onchain communications/“spots” (per the whitepaper); a governance role of the token is claimed.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) knowledge graph + embeddings profiling
Use‑case (use_case) personalization for dApps/agents
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 2 / 3 / 2
Last verified 2026-02-11

General project overview

Bluwhale describes itself as a decentralized personalization protocol for blockchain applications. The problem the project targets: personalization requires large data sets and is usually implemented in Web2 “walled gardens”; at the same time, users do not control their profiles and do not share in the distribution of the value created.

In the whitepaper, the project proposes to:

  • collect/aggregate onchain signals and context,
  • turn them into a queryable layer (knowledge graph + a vector‑graph layer),
  • give dApps/algorithms/agents the ability to quickly obtain personalization (segmentation, “similar wallets”, scoring),
  • support a model where access to data/communications is monetized and distributed through the protocol economy.

Features/modules

  • User knowledge graph / profiling: profiling of wallets and users, including multi‑wallet identification (claimed).
  • Embedding space architecture: a shift from “heavy graphs” to embedding spaces for fast search across millions of users (claimed).
  • Wallet dashboard / project dashboard: showcases/dashboards per wallet and per project (the whitepaper lists the functions: holdings, PnL, similar wallets, labeling, score).
  • On-chain messaging: a mechanism for communicating with wallets and an economy of “spots/queues”.
  • Use‑to‑Earn: rewards to users for participation/verification/unlocking “spots”.

Typical scenarios

  • Scenario 1 (dApp personalization): a dApp connects the profile layer → receives segments/embeds recommendations → users get a more relevant UX.
  • Scenario 2 (marketing/communications): a project sends messages to holders/segments → pays for the communication → users monetize “spots”.
  • Scenario 3 (analytics): an analyst/project looks at “similar wallets”, labeling and score → makes decisions on campaigns/product.

Getting started (wallet/network)

  • What you need: access to the project’s products/interfaces (per the website/whitepaper); an EVM wallet — if onchain interaction with the token is required.
  • Network/chain: BNB Smart Chain (the BLUAI token).
  • Fees: BNB Chain network gas for onchain operations with the token; the terms of “spots/communications” are described conceptually in the whitepaper.

Architecture/tech (non‑AI)

  • Components: offchain analytics/profile building (graph/embeddings), onchain contracts/token accounting, queue/communication mechanics, client dashboards.
  • Participant roles: users/wallets, dApps/client projects, protocol participants/operators (in the whitepaper — users/“dApps in queue”).
  • Where logic runs: AI profiling and analytics — offchain; payments/accounting/some rights and communications — onchain.
  • Dependencies: blockchain data (multi‑chain is mentioned), indexing/analytics infrastructure, BNB Chain for the BLUAI token.

Token/economics (expanded, no forecasts)

  • Token utility: the whitepaper describes BLUAI as the “currency” of the use‑to‑earn/insights ecosystem, as well as a governance role.
  • Who pays: dApps/companies that compete for communication/access pay for messages/the queue; users receive a share of the economy via “spots” (per the whitepaper).
  • Issuance: max total supply 10B BLUAI (per BscScan).
  • Governance: the whitepaper separately describes the governance role of the token (a formulation at the concept level).

Governance

  • Who makes decisions: not established (the whitepaper mentions the governance role of the token, but without describing the process).
  • How protocol parameters change: — (no Tier‑1 update/voting process found).
  • Where decisions are discussed/made: — (no Tier‑1 forum/repo/discussion process found).
  • Keys/multisig: — (no Tier‑1 information on keys/multisig found).

Security and incidents

  • Audits: — (no Tier‑1 audit reports found).
  • Bug bounty: — (no Tier‑1 bug bounty found).
  • Incidents: — (no Tier‑1 postmortems/incidents found).
  • Threat model: privacy/consent risks (wallet profiling), centralization risks of the offchain analytics, correctness risks of “similar wallets/scoring”.

Project status and timeline

  • Current status: active (public website/whitepaper + a token on BNB Chain).
  • Key releases/milestones: — (no Tier‑1 list of releases/milestones recorded).
  • Roadmap: — (no Tier‑1 roadmap found).

Ecosystem/integrations

  • Integrations: not established (no Tier‑1 list of integrations found).
  • Partners: — (no Tier‑1 confirmed list of partners found).
  • Where it’s actually used: as a profiling/personalization layer for dApps/agents (per the description in the whitepaper).

AI component of the project

  • What is real AI here? Building knowledge graphs/embeddings, AI profiling of wallets/users, “similar wallets”, scoring/labeling (per the whitepaper).
  • What is truly onchain? The BLUAI token and some economic actions (payments/accounting of communications), plus the use of onchain data as input to profiling.
  • Why is a token needed? The use‑to‑earn and communications/access economy; a governance function.
  • Red flags (based on the information found): onchain‑washing — medium risk (the AI part can run offchain); what to double‑check: exactly which onchain contracts provide the key properties and how privacy/consent is implemented.

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity medium 2
Token necessity high 3
Evidence Tier‑1 present 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): — (there are AI_1/AI_4: what the AI layer does and the architectural elements are described).
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): AI_0 applies only if AI_1..AI_4 = 0.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI profiling of users/wallets: a knowledge graph/vector‑graph layer, “AI‑driven profiling”, embeddings for fast queries and personalization.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): The whitepaper describes the purpose of the AI layer and the key AI subsystems (profiling/embeddings).
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): The whitepaper contains no reproducible demo/examples of model outputs (there is a description of dashboards/functions).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): Public examples/cases with reproducible results are needed.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): No quantitative quality metrics of profiling/embeddings are provided.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): The approaches (knowledge graph + embedding space), a hybrid profiling model and modules (dashboard, labeling, similar wallets) are described.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): There is a technical description at the level of architectural blocks and principles, although without specifics on models/versions.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain (mainnet)
  • Addresses/identifiers: BLUAI BEP‑20 contract 0xed9Ae3DEF8d6F052971Bb8b6d1975FF267Cf9aaD
  • Evidence: Tier‑1 — https://bscscan.com/token/0xed9Ae3DEF8d6F052971Bb8b6d1975FF267Cf9aaD
  • Why sufficient / why not (one line): The explorer confirms the token contract and the supply parameters.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: The economy of onchain messages/queues (“spots”), token incentives, as well as the use of onchain data as raw material for profiles.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): The whitepaper describes onchain communications and use‑to‑earn mechanics that go beyond “just a token”.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: personalization/profiling can also be implemented in a centralized system; the criticality of the blockchain as an irreplaceable property is not proven.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): The whitepaper has no strict argument that “without the blockchain the product breaks down”; onchain rather strengthens rights/incentives.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a token, BLUAI (BEP‑20).
  • Evidence: Tier‑1 — https://bscscan.com/token/0xed9Ae3DEF8d6F052971Bb8b6d1975FF267Cf9aaD
  • Why sufficient / why not (one line): The explorer confirms the existence of the token and its parameters.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): BLUAI is used as the currency for services/messages in the ecosystem (together with the chain gas token).
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): The whitepaper describes the use of BLUAI as a currency on the platform.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): Token incentives are described in the use‑to‑earn economy (rewards for participation/verifications/activities).
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): The whitepaper explicitly calls BLUAI a currency and describes the incentive system.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): BLUAI is claimed as a governance token (voting on proposals).
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): The whitepaper lists the governance role of the token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): In the project’s model the token acts as the main currency and the governance/incentive layer; replacing it with a subscription changes the design.
  • Evidence: Tier‑1 — https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf
  • Why sufficient / why not (one line): In the whitepaper the token is embedded in the “spots/queues” economy and governance.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://cdn.prod.website-files.com/63eeffaede17fe02b68b432c/664caca3de6c800fefb685b7_Bluwhale%20Whitepaper%20V2pdf.pdf The AI thesis/architecture (knowledge graph, embeddings), use‑to‑earn and the governance role of the token.
Tier‑1 https://bscscan.com/token/0xed9Ae3DEF8d6F052971Bb8b6d1975FF267Cf9aaD Onchain confirmation of the BLUAI token (contract, max supply).
Tier‑2 — —
Tier‑3 — —

No comments to display

Back to top