Skip to main content

META FINANCIAL AI

META FINANCIAL AI (MEF‑AI) — 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).

MEF‑AI — an AI/Agents / FinTech project: an “AI powered crypto trading assistant” and a set of analytics/signals, access to which (per the docs) is tied to the MEFAI utility token on the BNB Smart Chain network.

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: a service/product for trading with AI hints/signals and risk management tools.
  • Who it’s for: retail and institutional traders/investors (as claimed in the docs).
  • Why onchain/token: the token is needed as a key to paid features/access and for the buyback/burn mechanics (per the docs); the blockchain is used as the carrier of the token.

How it works (very briefly)

  1. The user does: connects to the product/receives signals and analytics (per the service model).
  2. The system does: generates signals by applying hybrid models and a DRL agent for risk parameters (claimed).
  3. The user gets: trading signals and a factor report (XAI) + risk management tools.
  4. Where the blockchain is: the MEFAI token on BNB Smart Chain; onchain accounting of supply/holders.
  5. Token role (if any): access to premium features/analytics, as well as support for the burn mechanics (per the docs).

Quick links: AI thesis fit

Project passport

Field Value
Project name META FINANCIAL AI
Also known as (aliases) MEF‑AI, MEFAI
Logo (logo) ../assets/252_meta-financial-ai_logo.png
Token symbol (ticker) MEFAI
Category AI/Agents | DeFi
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) — (not confirmed by Tier‑1)
Project status (status) active
Token (standard) BEP-20
Token contract 0x45e57907058c707a068100de358ba4535b18e2f3
Token model (token_type) utility (governance)
Max supply 1,000,000,000 MEFAI (per BscScan)
Issuance fixed + burn mechanism from revenue (as claimed)
Tokenomics (tokenomics, brief) MEFAI — the key to premium features; a buyback+burn mechanism is claimed; the docs also state “team holds no tokens”.
Governance — (not disclosed)
Admins/keys —
Audit —
Bug bounty —
Team (team) — (not found)
Funding (investors/funding) —
AI component (ai_component) trading signals, DRL risk management
Use‑case (use_case) AI assistant for crypto trading
DecAI Fit — AI thesis fit 4/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 1 / 2 / 3
Last verified 2026-02-11

General project overview

In its documentation, MEF‑AI describes itself as an “AI powered decision support ecosystem” for trading crypto assets: signal generation and quantitative decision support, including “Hybrid Predictive Models” (Temporal Fusion Transformer + LightGBM) and a DRL agent for dynamic risk management, plus an “Explainable AI” factor report.

Features/modules

  • Signals/analytics: realtime signals across many assets are claimed.
  • Risk management: a DRL agent for position sizing/stop loss (claimed).
  • Explainable AI: factor reports on signals (claimed).
  • Token access: MEFAI as the key to premium features + burn mechanics (claimed).

Typical scenarios

  • Scenario 1: a user connects a wallet to the panel → gets access to the Public/Pro/Prime tier and views AI signals/tables (per the quick start guide).
  • Scenario 2: a user configures risk parameters (leverage/TP/SL) → the system attaches auto TP/SL levels to signals and notifications (per the quick start guide).
  • Scenario 3: a user buys a subscription/package for MEFAI → part of the tokens is burned per the “paid-for transactional burn” mechanics (per the burn mechanism / tokenomics).

Getting started (wallet/network)

  • What you need: connect a wallet (MetaMask/Trust Wallet/WalletConnect) to the MEF AI Trading Panel; the access tier (Public/Pro/Prime) is verified via the wallet address (per the quick start guide).
  • Network/chain: BNB Smart Chain (the MEFAI token — BEP‑20).
  • Fees: BNB Chain network fees (BNB) for onchain operations with the token; interacting with the panel/viewing signals, per the description, does not require “spending permission” (per the quick start guide).

Architecture/tech (non‑AI)

  • Components: the MEFAI token contract (BSC), a web panel/application with signals and settings, an offchain AI/analytics stack (generation of signals/tables/notifications) per the description in the docs.
  • Participant roles: panel users (Public/Pro/Prime), token holders/subscribers, the team/platform operators.
  • Where logic runs: the token economy and onchain accounting — BNB Smart Chain; signal generation/AI models and the panel interface — offchain (by the nature of the product).
  • Dependencies: BNB Smart Chain (token), the panel’s web infrastructure and notification/widget integrations (TradingView/Telegram/Discord — in the roadmap as plans/in progress).

Token/economics (expanded, no forecasts)

  • Token utility: the “key” to premium features/subscriptions and advanced analytics; the docs describe subscription packages and confirmation of the access level via the wallet.
  • Protocol necessity drivers: in the docs, the token is directly tied to access to the product (subscriptions), as well as to the burn mechanics, which is triggered “from each package subscription fee, paid in MEFAI tokens”.
  • Who pays fees: users pay BNB Chain fees when buying/transferring the token and for other onchain operations; subscriptions/package purchases are described in the docs as payments in MEFAI.
  • Where fees go: network fees — to BNB Chain validators; per the docs, the protocol part of package payments is partly directed to burn (an irreversible burn address); other directions (team/operational) are not detailed in the extracted Tier‑1.
  • Issuance/burn: fixed supply (the docs emphasize: no mint function / fixed supply); a burn scheme is described: (a) unsold presale tokens burn; (b) part of each package payment is burned (“paid-for transactional burn”). The tokenomics also specify buy/sell taxes (1.00% / 0.99%) and a burn rule via referral transactions (25% burned from the referral system’s transactions — per the tokenomics).
  • Security/incentive mechanisms: incentives via a referral program (50% referral income; the tokenomics state that part of the transactions is burned); staking/slashing are not described as key mechanics.
  • Distribution and token issuance schedule: the tokenomics claim “0% team tokens” and “100% community ownership”, without treasury/airdrop/development wallets; vesting schedules/lockups are not provided.
  • Treasury: the tokenomics state that there is no treasury wallet; how operational expenses are financed is not disclosed in the extracted Tier‑1.

Governance

  • Who makes decisions: — (DAO/onchain governance are not described in the extracted Tier‑1; probably the project team).
  • How protocol parameters change: via product/documentation updates and, if necessary, token/contract upgrades (the roadmap has an item about a token transition / zero tax upgrade).
  • Where decisions are discussed/made: the official GitBook documentation and the project’s channels (X/Telegram are listed in the links of this card).
  • Keys/multisig: — (not found in the extracted Tier‑1)

Security and incidents

  • Audits: the tokenomics list pages of independent “scans/reports”: QuickIntel, Honeypot.is, GoPlus Labs (as links for verification). A full audit PDF is not presented in the extracted Tier‑1.
  • Bug bounty: — (not found in the extracted Tier‑1)
  • Incidents: — (not found in the extracted Tier‑1)
  • Threat model: risks of the quality of the AI signals/models (offchain), access control risks (subscriptions), risks of the token contract/taxes and of the correctness of the burn mechanics.

Project status and timeline

  • Current status: the product is active (the docs are being updated; the roadmap marks items as completed/in progress).
  • Key releases/milestones: 2024 — Initial Signal Engine Launch (completed), Referral System Activation (completed); 2025 — Autotrade launch (Oct 1, 2025; completed) and mobile app (in progress); 2026+ — planned AI Signal API and “AI Model Upgrades (MEFAI v2, Q2 2026)” and other items (per the roadmap).
  • Roadmap: https://mefai.gitbook.io/mefai-docs/other/roadmap

Ecosystem/integrations

  • Integrations: wallet connect (MetaMask/Trust Wallet/WalletConnect — in the quick start guide); planned/in‑progress integrations of notifications and tools (TradingView/Telegram/Discord) are listed in the roadmap.
  • Partners: — (no confirmed partnerships found in the extracted Tier‑1)
  • Where it’s actually used: the main use case is access to the trading panel/signals and paid packages (described in the quick start guide and the sections on tokenomics/burn).

AI component of the project

  • What is real AI here? time series forecasting models, “market regime” classification and a DRL risk management module are claimed.
  • What is truly onchain? the MEFAI token on the BNB Smart Chain network; the trading logic itself and the models — offchain (by the nature of the product).
  • Why is a token needed? access to premium features/analytics and participation in the burn mechanics (per the docs).
  • Red flags (based on the information found): AI‑washing — there are no independent metrics/benchmarks in the extracted Tier‑1; onchain‑washing — the blockchain is mostly a token wrapper; token‑washing — it needs to be verified that access is actually enforced via the token.

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): There are signs of AI reality per Tier‑1 (see AI_1..AI_4), so the AI_0 flag (intent‑only) does not apply.
  • Evidence: Tier‑1 — see Evidence/links in AI_1..AI_4.
  • Why sufficient / why not (one line): AI_0=1 is admissible only when AI_1..AI_4=0; here ai_score without AI_0 = 2.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): a TFT forecasting model, LightGBM “regime” classification, a DRL risk management module and XAI reports are claimed.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): this is a sufficiently specific description of the AI functions.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a verifiable demo/public examples of signals are not confirmed in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): the page is descriptive, without a replicable demo.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): there are no reproducible accuracy/return/risk metrics with experimental conditions.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): a “Quantum Fusion Architecture” and the composition of the models (TFT/LightGBM/DRL/XAI) are described at a high level.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): there is a description of the architectural blocks, albeit without code/benchmarks.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain.
  • Addresses/identifiers: 0x45e57907058c707a068100de358ba4535b18e2f3.
  • Evidence: Tier‑1 — https://bscscan.com/token/0x45e57907058c707a068100de358ba4535b18e2f3
  • Why sufficient / why not (one line): BscScan confirms the contract, max supply and metadata.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: other than the token, onchain logic (signals/trading) is not shown in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): per the description, the product is offchain.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the AI service could work without a blockchain; onchain is needed mainly for the token.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): there is no proof of the irreplaceability of onchain.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the MEFAI token exists.
  • Evidence: Tier‑1 — https://bscscan.com/token/0x45e57907058c707a068100de358ba4535b18e2f3
  • Why sufficient / why not (one line): BscScan.
  • 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): MEFAI is used for access to premium features and advanced analytics.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): stated in docs.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): a buyback+burn mechanism financed by revenue is claimed.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): docs mention continuous buyback and burn.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): the governance role of the token is not confirmed in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): there is no explicit governance section.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): strict proof of the irreplaceability of the token is absent in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://mefai.gitbook.io/mefai-docs
  • Why sufficient / why not (one line): the token’s utility is described as a “key”, but this can be implemented differently as well.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://mefai.gitbook.io/mefai-docs Description of the AI architecture (TFT/LightGBM/DRL/XAI) and the role of the MEFAI token (utility + burn).
Tier‑1 https://bscscan.com/token/0x45e57907058c707a068100de358ba4535b18e2f3 The MEFAI contract and max supply 1B.
Tier‑2 https://coinmarketcap.com/currencies/meta-financial-ai/ Reference profile.
Tier‑3 https://mefai.io/whitepaper The whitepaper URL is listed in this card; the content was not verified.

No comments to display

Back to top