Skip to main content

Legend

Legend (LEGEND) — 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).

Legend — a project on the Base network; it claims AI agents for sports analytics/reports; token (symbol: LEGEND).

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 application/ecosystem with sports prediction mechanics and digital rewards.
  • Who it’s for: sports fans and communities; Telegram/social media users.
  • Why onchain/token: the Tier‑1 docs describe “match staking” and “time‑locked staking” for the $LEGEND token on Base ($LEGEND and ETH on Base for gas are needed).
  • What you can actually touch (Tier‑1): the staking application stake.belegends.com + documentation on match staking; the website also has an “Ask the Agent” link to @LegendAIAgent on X.

How it works (very briefly)

  1. The user does: connects a wallet, selects a match pool and stakes $LEGEND on Base, distributing the stake across outcomes (per the Tier‑1 docs).
  2. The system does: records onchain stakes/changes before the start of the match; after the match, allows claiming the stake and rewards (per the Tier‑1 docs).
  3. The user gets: content/analytics and the result of participation in the prediction mechanic.
  4. Where the blockchain is: Base (staking pools in the dApp + the ERC‑20 token $LEGEND).
  5. Token role (if any): the token is used as an asset for staking in pools and receiving rewards in $LEGEND (per the Tier‑1 docs).

Quick links: AI thesis fit

Project passport

Field Value
Project name Legend
Also known as (aliases) LEGEND, $LEGEND
Logo (logo) —
Token symbol (ticker) LEGEND
Category AI/Agents | DeFi
Primary chain (chain) Base
Type EVM
Network status mainnet
Consensus (consensus) PoS (Base; Ethereum L2)
Launch date (launch_date) 2025-01-15 (listing, per the docs)
Project status (status) active
Token (standard) ERC-20
Token contract 0xc7837be3d71e00fcbe76d77602bcf353df859664
Token model (token_type) utility (staking + prediction markets)
Max supply 412,866,702.145034208934462724
Issuance —
Tokenomics (tokenomics, brief) Tier‑1: match staking / time‑locked staking pools on Base; rewards in $LEGEND.
Governance —
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) AI agents for sports forecasts/reports
Use‑case (use_case) sports (match predictions + content)
DecAI Fit — AI thesis fit 4/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 2 / onchain_score 2 / token_score 1 / evidence_score 3
Last verified 2026-02-11

General project overview

Legend positions itself as a sports digital ecosystem with prediction and audience engagement mechanics, as well as a showcase of digital rewards. Per Tier‑1 sources, it is confirmed that the project mentions AI agents for sports analytics/reporting and has the $LEGEND token on the Base network. The Tier‑1 docs also describe a staking product (match staking and time‑locked staking) for $LEGEND on Base.

Features/modules

  • Match prediction mechanic (per the description on the website).
  • AI agents/assistants for match reports and content (per the description on the website).
  • Showcase/gallery of rewards (museum/gallery).

Typical scenarios

  • Scenario 1: a user reads/receives match reports and analytics from AI agents.
  • Scenario 2: a user participates in match predictions within the project’s mechanic.
  • Scenario 3: a user views/showcases digital rewards in the gallery.

Getting started (wallet/network)

  • What you need: an account/access to the project’s products (via the links in the links_* section).
  • Network/chain: Base (for interacting with the token/onchain part).
  • Fees: Base network fees (if onchain transactions are performed).

Architecture/tech (non‑AI)

  • Components: per Tier‑1, the token contract on the Base network is confirmed; the rest of the architecture (contracts/backend/clients) is not disclosed in detail in the available sources.
  • Participant roles: users/communities (per the description on the website).
  • Where logic runs: per Tier‑1, the onchain level of the token on Base is confirmed; the rest — not established.
  • Dependencies: —.

Token/economics (expanded, no forecasts)

  • Token utility: Tier‑1 docs: $LEGEND is used as an asset for staking in match staking and time‑locked pools on Base.
  • Protocol necessity drivers: the staking mechanics are described as part of the product; without $LEGEND (as the stake asset) this product does not work in its current form.
  • Who pays fees: users, if they perform onchain operations on Base.
  • Where fees go: to Base validators (as network fees), if transactions are performed.
  • Issuance/burn: not established.
  • Security/incentive mechanisms: not established.
  • Distribution and token issuance schedule: not established.
  • Treasury: not established.

Governance

  • Who makes decisions: not established.
  • How protocol parameters change: not established.
  • Where decisions are discussed/made: not established.
  • Keys/multisig: not established.

Security and incidents

  • Audits: not established.
  • Bug bounty: not established.
  • Incidents: not established.
  • Threat model: not established.

Project status and timeline

  • Current status: the website and the onchain token are active; the rest — not established.
  • Key releases/milestones: not established.
  • Roadmap: not established.

Ecosystem/integrations

  • Integrations: not established.
  • Partners: the website has links to external materials/mentions (for example, the IOC case study PDF), but formal Tier‑1 lists of partners/terms are not recorded.
  • Where it’s actually used: not established.

AI component of the project

  • What is real AI here? Per the description on the official website, the project claims AI agents/assistants for generating match reports and helping with predictions.
  • What is truly onchain? The ERC‑20 token $LEGEND on the Base network + onchain staking/pools in the dApp stake.belegends.com (described in the Tier‑1 docs).
  • Why is a token needed? The Tier‑1 docs describe $LEGEND as a mandatory asset for participating in staking pools and receiving rewards.
  • Red flags (based on the information found): the AI part is described at the level of claims without a tech description/metrics; the criticality of onchain for the sports “reports/agents” is not established.

DecAI Fit component summary

  • DecAI Fit: 4/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality medium 2
Onchain necessity medium 2
Token necessity low 1
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 intentions in roadmap format as a separate artifact are not established.
  • Evidence: Tier‑1 — https://www.belegends.com/
  • Why sufficient / why not (one line): no separate roadmap/official update with AI plans (as intent) was found; there is only a general description of AI agents on the website.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the website claims AI agents for generating match reports and helping with predictions.
  • Evidence: Tier‑1 — https://www.belegends.com/
  • Why sufficient / why not (one line): The Tier‑1 source describes the purpose of the AI agents, which is sufficient for “what the AI does is described”.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): The website has an “Ask the Agent” link to the account @LegendAIAgent (as a demo surface).
  • Evidence: Tier‑1 — https://www.belegends.com/ ; https://x.com/LegendAIAgent
  • Why sufficient / why not (one line): The Tier‑1 website provides a reproducible interaction surface (via X); at the same time, quality metrics of the AI part are not disclosed (AI_3=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://www.belegends.com/
  • Why sufficient / why not (one line): metrics/benchmarks with context and artifacts were not found.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): the tech description/architecture/versions of the models are not established per Tier‑1.
  • Evidence: Tier‑1 — https://www.belegends.com/
  • Why sufficient / why not (one line): without tech docs/versions we set 0.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base
  • Addresses/identifiers: 0xc7837be3d71e00fcbe76d77602bcf353df859664 (ERC‑20 token)
  • Evidence: Tier‑1 — https://basescan.org/token/0xc7837be3d71e00fcbe76d77602bcf353df859664
  • Why sufficient / why not (one line): The Tier‑1 onchain source records the network and the address of the token/contract.
  • Conflict note (if any): —

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

  • OC_2 (decision): 1
  • What useful logic is onchain: staking pools (match staking and time‑locked staking) on Base: staking/changes and claims are executed as onchain transactions (per the docs).
  • Evidence: Tier‑1 — https://stake.belegends.com/docs/match-staking ; https://stake.belegends.com/docs/time-staking
  • Why sufficient / why not (one line): There is a Tier‑1 description of useful onchain logic beyond the existence of the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: it is not established what exactly breaks down without onchain per Tier‑1.
  • Evidence: Tier‑1 — https://stake.belegends.com/docs/match-staking
  • Why sufficient / why not (one line): no justification of onchain criticality was found, we set 0.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, LEGEND, on the Base network.
  • Evidence: Tier‑1 — https://basescan.org/token/0xc7837be3d71e00fcbe76d77602bcf353df859664
  • Why sufficient / why not (one line): The Tier‑1 onchain source confirms the existence of the token.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): no Tier‑1 confirmation was found that the token is used to pay for a specific service.
  • Evidence: Tier‑1 — https://stake.belegends.com/docs/match-staking
  • Why sufficient / why not (one line): without a specification of payments in Tier‑1 we set 0.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): $LEGEND is used as the stake asset in pools with rewards in $LEGEND (match staking / time‑locked staking).
  • Evidence: Tier‑1 — https://stake.belegends.com/docs/match-staking ; https://stake.belegends.com/docs/time-staking
  • Why sufficient / why not (one line): The Tier‑1 docs describe staking and receiving rewards in the token.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): no Tier‑1 confirmation of governance via the token was found.
  • Evidence: Tier‑1 — https://www.belegends.com/
  • Why sufficient / why not (one line): without governance documents/contracts/process we set 0.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the replaceability/irreplaceability of the token is not established per Tier‑1.
  • Evidence: Tier‑1 — https://stake.belegends.com/docs/match-staking
  • Why sufficient / why not (one line): without the token design and protocol rules we do not draw a conclusion about replaceability.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://www.belegends.com/ The official website describes the product and claims AI agents (purpose/modules).
Tier‑1 https://stake.belegends.com/docs/token Tier‑1: $LEGEND contract addresses (Ethereum + Base) and basic reference on the token.
Tier‑1 https://stake.belegends.com/docs/match-staking Tier‑1: match staking as an onchain mechanic on Base (staking $LEGEND, claiming the stake and rewards).
Tier‑1 https://stake.belegends.com/docs/time-staking Tier‑1: time‑locked staking for $LEGEND (staking portal).
Tier‑1 https://basescan.org/token/0xc7837be3d71e00fcbe76d77602bcf353df859664 Confirms the LEGEND token (ERC‑20) on the Base network: contract address and parameters (including Max Total Supply).
Tier‑1 https://go.belegends.com/whitepaper The project’s whitepaper (the link is present in Token Info on BaseScan).
Tier‑2 https://www.coingecko.com/en/coins/legend-2 Reference profile (not proof).

No comments to display

Back to top