Skip to main content

Metya

Metya (MY) — 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).

Metya — a Web3 “social + payments” platform (SocialFi/PayFi) where Tier‑1 sources claim application‑level AI features (matching, real‑time translation) and onchain anchoring of some transactions/rewards. The MY token is a BEP‑20 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 “social + payments” app (dating/social interactions + payments/card) with the MY token on BNB Chain.
  • Who it’s for: app users; creators/community; merchants (per the project’s claim).
  • Why onchain/token: the MY token is used for payments/fees/boosts/staking/governance (per Tier‑1 docs); the onchain part is described in Tier‑1 in general terms, without a full list of contracts beyond the token.
  • What you can actually touch (Tier‑1): the Metya whitebook/docs (description of features and user scenarios) and the project’s official website.

How it works (very briefly)

  1. The user does: uses the app (social interactions/transactions), can hold/spend MY/USDT.
  2. The system does: the app’s offchain logic (AI matching/translation) + onchain anchoring of individual transactions/rewards; the MY token circulates as a BEP‑20.
  3. The user gets: social interactions and a payment layer (card/conversion) + an onchain token.
  4. Where the blockchain is: the MY token and its transfers — onchain on BNB Smart Chain; the rest — a mixed offchain/onchain architecture.
  5. Token role: payments/fees/boosts/tiers/staking/governance (as described in the Tier‑1 documentation).

Quick links: AI thesis fit

Project passport

Field Value
Project name Metya
Also known as (aliases) MetYa | MY
Logo (logo) ../assets/metya_logo.svg
Token symbol (ticker) MY
Category AI/Other | SocialFi | PayFi
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) —
Project status (status) active
Token (standard) BEP-20
Token contract 0xf0ebb572643336834d516c485ad31d3299999999
Token model (token_type) utility (payments + staking + governance)
Max supply —
Issuance —
Tokenomics (tokenomics, brief) Tier‑1: sources/sinks and the utility of MY are described; the numerical supply/distribution parameters require re‑checking against onchain/docs
Governance governance (claimed; the detailed process is not formalized in Tier‑1)
Admins/keys —
Audit yes (CertiK; project link)
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI matching + real-time translation (app)
Use‑case (use_case) social + payments app with token
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 1 / 0 / 3
Last verified 2026-02-11

General project overview

In its Tier‑1 documentation, Metya describes itself as a “Web3 social‑payments platform (PayFi + SocialFi)”, where social actions and interactions are meant to become “spendable value”. At the application level, AI functions are claimed: AI‑driven matching and real‑time translation. At the blockchain level, the onchain MY token on BNB Smart Chain is confirmed; some “critical transactions/rewards” are described as anchored onchain, but without a full list of contracts.

Features/modules

  • Social layer of the app: matching/communications; AI matching and translation are claimed.
  • Payment layer: a “Metya Card” and MY/USDT conversion for spending (within compliance) are claimed.
  • MY token: utility for payments/fees/boosts/tiers/staking/governance (Tier‑1).

Typical scenarios

  • Scenario 1: a user uses the app → performs actions/receives rewards → holds/spends MY.
  • Scenario 2: a user uses the payment functions (top‑up/spending) → some operations are recorded onchain (as claimed).

Getting started (wallet/network)

  • What you need: an EVM wallet for BNB Smart Chain (for the token) + access to the app/payment part (as described by the project).
  • Network/chain: BNB Smart Chain.
  • Fees: gas in BNB for BEP‑20 operations; additional fees/limits in the payment layer — per the terms of service.

Architecture/tech (non‑AI)

  • Components: a mobile/web app + payment infrastructure (offchain) + the MY token (onchain).
  • Participant roles: users; (possible) creators/merchants; the service operator (in the payment part).
  • Where logic runs: AI features and payments — predominantly offchain; the token and transfers — onchain.
  • Dependencies: BNB Smart Chain; payment infrastructure/compliance providers (per the claims).

Token/economics (expanded, no forecasts)

  • Token utility: the Tier‑1 documentation lists payment use cases (card top‑up/settlement/fees), social use cases (boosts/unlocks/tipping/task incentives), staking/tiers and governance.
  • Protocol necessity drivers: part of the functionality is tied to MY as the “primary asset” within the ecosystem; at the same time (per the replaceability test) some functions could be implemented via other assets/a subscription.
  • Who pays fees: users (gas in BNB) + service users (per the service’s tariffs/fees).
  • Issuance/burn: Tier‑1 mentions sinks and burn mechanics as a concept; the exact onchain parameters require re‑checking on the contract/in the docs.

Governance

The Tier‑1 docs claim governance over parameters (fees/limits/SIP weights/buyback/burn windows/unlocks). An onchain voting mechanism/addresses of governance contracts are not presented as separate artifacts — clarification is required.

Security and incidents

Project status and timeline

  • Current status: the project is active (per the official pages).
  • Roadmap: published in the Tier‑1 docs.

Ecosystem/integrations

  • Integrations: BNB Smart Chain; external partners/payment rails — are claimed, but require independent verification against the partners’ Tier‑1 documents.

AI component of the project

  • What is real AI here? the Tier‑1 docs describe AI matching and real‑time translation as capabilities of the app.
  • What is truly onchain? the MY token on BNB Smart Chain; the rest of the logic is described in Tier‑1 as “anchored on-chain”, but without contract addresses beyond the token.
  • Why is a token needed? the utility is listed (payments/social boosts/staking/governance), but some functions are potentially replaceable with alternative assets/a subscription.
  • Red flags (based on the information found): AI‑washing (AI consists of app features, not a “decentralized AI protocol”); onchain‑washing (apart from the token, onchain artifacts are not listed by address); token‑washing (check whether MY is really mandatory for the service and which parameters are implemented in the contract).

DecAI Fit component summary

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

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): AI is described as current features of the app, not as “intent only, without a product”.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya
  • Why sufficient / why not (one line): AI intent as a roadmap placeholder is not needed, since there are described AI capabilities.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI‑driven matching and real‑time translation are claimed.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya
  • Why sufficient / why not (one line): the capability is listed in the Executive Summary (“AI-driven matching and real-time translation”).
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there is a reproducible product scenario (the app) and a description of working functions.
  • Evidence: Tier‑1 — https://metya.com/whitepaper.pdf
  • Why sufficient / why not (one line): the whitepaper/website describes the product and its functions; a separate public “AI demo endpoint” is not required for a basic 1/0.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya
  • Why sufficient / why not (one line): no quantitative AI quality metrics (accuracy/latency/translation quality, etc.) were found.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is no technical description of an AI model/versions/architecture in a volume sufficient for a 1/0.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya
  • Why sufficient / why not (one line): capabilities are described, but not the architecture/versions of the models.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: BNB Smart Chain
  • Addresses/identifiers: MY token (BEP‑20): 0xf0ebb572643336834d516c485ad31d3299999999
  • Evidence: Tier‑1 — https://bscscan.com/token/0xf0ebb572643336834d516c485ad31d3299999999
  • Why sufficient / why not (one line): the token address and the onchain asset are verifiable in the explorer.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: Tier‑1 has no list of onchain contracts/addresses (other than the token) that implement the app’s key business logic.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya
  • Why sufficient / why not (one line): there are general “anchored on-chain” statements, but without addresses/artifacts.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the product’s core value is described as an app + payments; the blockchain could be replaced without a complete loss of meaning (apart from the existence of the token).
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya
  • Why sufficient / why not (one line): Tier‑1 does not prove that onchain is critical for the operation of the app as a service.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the MY token exists as a BEP‑20 on BNB Smart Chain.
  • Evidence: Tier‑1 — https://bscscan.com/token/0xf0ebb572643336834d516c485ad31d3299999999
  • Why sufficient / why not (one line): the token is visible in the explorer.
  • 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): MY is claimed as the asset for payment use cases and fees/discounts within the ecosystem.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya/token-usdmy
  • Why sufficient / why not (one line): the Token ($MY) section lists the payments utility and the fee mechanics.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): staking/tiers are claimed, but Tier‑1 has no verifiable onchain artifacts (contracts/parameters) for a strict 1/0.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya/token-usdmy
  • Why sufficient / why not (one line): there is a description, but without onchain‑verifiable details.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance is described as a possibility, but specific mechanisms/addresses/voting processes are absent in Tier‑1.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya/token-usdmy
  • Why sufficient / why not (one line): there is a declaration, but not a proof‑level description of governance.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): for payments/subscriptions/boosts the token is in principle replaceable with other assets (e.g. stablecoins) without loss of the service’s meaning.
  • Evidence: Tier‑1 — https://metya.gitbook.io/metya
  • Why sufficient / why not (one line): Tier‑1 does not show a unique protocol‑level necessity of MY.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://metya.gitbook.io/metya Executive Summary: AI matching and real‑time translation; overall positioning of the product
Tier‑1 https://metya.com/whitepaper.pdf description of the product and the claimed functions/scenarios
Tier‑1 https://metya.gitbook.io/metya/token-usdmy utility of MY (payments/social/fees/boosts), claimed mechanics
Tier‑1 https://bscscan.com/token/0xf0ebb572643336834d516c485ad31d3299999999 onchain fact: the MY token and its address on BNB Smart Chain
Tier‑1 https://skynet.certik.com/projects/metya external security audit/monitoring page (CertiK)

No comments to display

Back to top