Skip to main content

Fireverse

Fireverse (FIR) — 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).

Fireverse — an AI/Media / Music / Web3 project: an AI‑driven platform for music generation and its monetization with a Web3 model (points→token rewards; copyright management via smart contracts). Token: FIR (BEP‑20 on BNB Smart 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: a platform for generating/processing music with AI + Web3 mechanics for promotion and monetization.
  • Who it’s for: musicians/content creators, marketers and listeners participating in a campaign‑based/gamified economy.
  • Why onchain/token: the token is used for purchasing rights/digital goods and for reward mechanics; the blockchain is claimed for copyright and revenue distribution.

How it works (very briefly)

  1. The user does: creates a track via AI (text prompt/audio input), listens/shares/participates in tasks.
  2. The system does: generates/processes music with the AI engine; accrues points for activity; links campaigns and promo mechanics.
  3. The user gets: the created content and the ability to monetize/participate in reward programs (per the whitepaper).
  4. Where the blockchain is: smart contracts and onchain accounting for copyright protection and revenue distribution (claimed); the FIR token is on BNB Chain.
  5. Token role (if any): FIR — payments/purchase of rights/promo/content rewards and the “Listen & Share to Earn” economy (per the whitepaper).

Quick links: AI thesis fit

Project passport

Field Value
Project name Fireverse
Also known as (aliases) FIR, Fireverse Ventures
Logo (logo) ../assets/260_fireverse_logo.ico
Token symbol (ticker) FIR
Category AI/Media | Music | Web3
Primary chain (chain) BNB Smart Chain
Type EVM
Network status mainnet
Consensus (consensus) PoSA (BNB Smart Chain; 21 validators)
Launch date (launch_date) — (not found in the extracted Tier‑1)
Project status (status) active (the whitepaper has been updated; token on BSC)
Token (standard) BEP-20
Token contract 0x238d72e179a581c98dc1996417a49818c7e509dc
Token model (token_type) utility (governance)
Max supply 1,000,000,000 FIR (per BscScan)
Issuance fixed cap; burn available (ERC20Burnable)
Tokenomics (tokenomics, brief) total supply 1B; allocations/vesting are described in the whitepaper as a table.
Governance — (not found in the extracted Tier‑1)
Admins/keys — (the extracted Tier‑1 contain no data on timelock/multisig; the FIR contract is of a simple mint‑at‑deploy type)
Audit — (BscScan indicates that an audit was not submitted)
Bug bounty — (not found in the extracted Tier‑1)
Team (team) co-founders/roles in the whitepaper: Leo Tse (CTO), Barbie Man (co-founder), William Yang (COO), Ray Yu (CMO).
Funding (investors/funding) investors/funds are listed in the whitepaper (OKX Ventures, etc.).
AI component (ai_component) music generation (AI engine)
Use‑case (use_case) create/promo/monetize music
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 2 / 1 / 0 / 2
Last verified 2026-02-11

General project overview

Fireverse describes itself as an AI‑driven music generation platform where users can generate music, promote and monetize it with a Web3 model (gamification, campaigns, “listen & share to earn”). The whitepaper also claims the use of smart contracts to automate revenue distribution and “blockchain‑based copyright protection”.

Features/modules

  • AI Music Generation / processing: text‑to‑music and audio‑to‑music tools, one‑click AI processing (whitepaper).
  • Listen & Share to Earn: accrual of points for listening/sharing and activity, which can be converted into token rewards (whitepaper).
  • Campaign builder / competitions: campaigns, challenges, ambassador programs, contests (whitepaper).
  • Copyright and revenue distribution: smart contracts for workflow management and revenue distribution, protection of rights (whitepaper).

Typical scenarios

  • Scenario 1: a user enters a text prompt → receives an AI‑generated track → publishes/promotes it.
  • Scenario 2: a listener listens to and shares tracks → receives points → participates in future token airdrops based on the ranking (claimed).
  • Scenario 3: a marketer launches a campaign/challenge and sets reward conditions → stimulates listens/sharing.

Getting started (wallet/network)

  • What you need: an account/access to the product; for onchain operations and working with FIR — an EVM wallet.
  • Network/chain: BNB Smart Chain (FIR token).
  • Fees: BNB Chain gas for transfers/interactions with the token and (if applicable) the platform’s smart contracts.

Architecture/tech (non‑AI)

  • Components: the web platform, an offchain AI engine for generation/processing, points/reward mechanics; the onchain FIR token (BSC) and (claimed) smart contracts for copyright/revenue distribution.
  • Participant roles: creators (artists/creators), listeners, marketers (campaigns), FIR holders/users.
  • Where logic runs: AI generation — offchain; token accounting and onchain ownership/operations — onchain (BSC).
  • Dependencies: BNB Chain and EVM infrastructure; external distribution channels/partners (claimed in the whitepaper).

Token/economics (expanded, no forecasts)

  • Token utility: FIR is used for purchasing digital/physical goods and rights, purchasing music rights/albums, promo/marketing (traffic exposure, bounties), content rewards (tipping) — per the whitepaper.
  • Protocol necessity drivers: the utility is tied to the platform economy (purchases/promo/rewards) and the “Listen & Share to Earn” mechanics.
  • Who pays fees: users pay network gas (BNB) for onchain actions; the platform’s business logic may include fees/payments in FIR (per the description of the utility).
  • Where fees go: network fees — to the BNB Chain validators; the distribution of protocol fees is not described in the extracted Tier‑1.
  • Issuance/burn: cap of 1,000,000,000 FIR (per BscScan); burn is available in the token code (ERC20Burnable). A separate burn policy is not described in the whitepaper as parameterized.
  • Security/incentive mechanisms: points→airdrop (claimed: “Tokens will be airdropped in the future based on points rankings”); and the FIR utility for rewards/promo.
  • Distribution and token issuance schedule: the whitepaper provides a table of allocations/vesting: Private Investment 20% (12m cliff + 24m linear), Ecosystem Reward 10% (1m cliff + 24m linear daily), Staking Ecosystem Reward 30% (3m cliff + 12m linear daily), Marketing 11% (6m cliff; 30% at TGE + 12m quarterly), Liquidity 8% (1m cliff; 5% at TGE + 3% after 1m cliff), Advisors 5% (6m cliff + 24m linear daily), Treasury 6% (9m cliff + 24m linear daily), Team 10% (12m cliff + 48m linear monthly).
  • Treasury: Treasury allocation 6% (whitepaper); who controls it and how is not disclosed in the extracted Tier‑1.

Governance

  • Who makes decisions: the project team (per the whitepaper; a formal DAO is not described).
  • How protocol parameters change: via product/contract updates (governance details not disclosed in the extracted Tier‑1).
  • Where decisions are discussed/made: the project’s public channels (X/Discord/Telegram/Medium).
  • Keys/multisig: — (not found in the extracted Tier‑1).

Security and incidents

  • Audits: the BscScan token page states “No Contract Security Audit Submitted”.
  • Bug bounty: — (not found in the extracted Tier‑1).
  • Incidents: — (not found in the extracted Tier‑1).
  • Threat model: risks of offchain AI/content, rights/copyright risks, risks of a centralized platform and a simple token contract; phishing risks (mirrors/unofficial dApps).

Project status and timeline

  • Current status: the product is claimed as active; the token is on BNB Chain.
  • Key releases/milestones: roadmap in the whitepaper: beta launch (Oct 2024), exchange listing (no later than Mar 2025), then plans for 2025 and 2026+.
  • Roadmap: https://fireverse-ventures.gitbook.io/white-paper#roadmap

Ecosystem/integrations

  • Integrations: the web product and the FIR token on BNB Chain; links to social media and community channels in the whitepaper/on BscScan.
  • Partners: the whitepaper claims “close partnerships with many renowned music companies and distribution platforms” without listing them in the extracted fragment; a collaboration with Nobody (Moonbox) as an IP partner is mentioned.
  • Where it’s actually used: — (no verifiable onchain usage metrics found in the extracted Tier‑1).

AI component of the project

  • What is real AI here? the whitepaper describes AI music generation and AI processing tools (GAN/RNN/LSTM/Transformers are mentioned as the applied classes of models).
  • What is truly onchain? the FIR token on BNB Chain; the whitepaper claims smart contracts for copyright management and revenue distribution.
  • Why is a token needed? the FIR utility: purchases, music rights, promo activities, rewards/tipping; plus participation in the reward economy.
  • Red flags (based on the information found): onchain‑washing — the whitepaper contains no addresses/proof of deployed copyright contracts; AI‑washing — no generation quality metrics; token‑washing — part of the functions can work without the token (internal points/fiat), and also web3.fireverseai.com is unavailable for extraction (unavailable per the available sources) — a manual check of the product is required.

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 2
Details

AI reality

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

  • AI_0 (decision): 0
  • Claim (one line): the AI component is confirmed by the description of functions and a (minimal) technical context, so “intent only without proof” does not apply.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): AI_0 is intended for cases where there is only a roadmap intent, but AI_1..AI_4 = 0; here AI_1/AI_4 ≠ 0.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the AI generates music from text prompts/audio inputs and performs “AI music processing tools”.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): the text‑to‑music/audio‑to‑music functionality is described, but without open technical details of the implementation.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no replicable demo/examples of generation quality were found in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): the whitepaper describes the product, but does not provide test protocols/examples of outputs.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: — (not found)
  • Context (version/date/how measured): — (not found)
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): there are no generation/processing quality metrics.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): the whitepaper lists the applied model families (GAN, RNN/LSTM, Transformers) and describes their purpose (music/sequences).
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): this is a minimal technical level (model classes), but without specific implementations/versions/datasets.
  • Conflict note (if any): —

Onchain necessity

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

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

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

  • OC_2 (decision): 0
  • What useful logic is onchain: the whitepaper claims smart contracts for copyright and revenue distribution, but the extracted Tier‑1 contain no addresses/proof of deployed contracts.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): there is a claim, but it is insufficient to verifiably count as “useful onchain logic”.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: if the blockchain is replaced with an ordinary server/DB, the core function is preserved (AI generation/processing of music and the web platform); the whitepaper claims the benefit of onchain for copyright/revenue distribution, but the extracted Tier‑1 contain no verifiable addresses/mechanics without which the product “breaks down”.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper ; https://bscscan.com/token/0x238d72e179a581c98dc1996417a49818c7e509dc
  • Why sufficient / why not (one line): onchain in the extracted data is confirmed at the level of the token and claims, but not proven as a critical part without which the product loses its meaning.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, FIR, on BNB Smart Chain.
  • Evidence: Tier‑1 — https://bscscan.com/token/0x238d72e179a581c98dc1996417a49818c7e509dc ; https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): the token is confirmed by the contract on BscScan and described in the whitepaper.
  • 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): FIR is used for purchasing rights/albums/goods and for promo/marketing (traffic exposure, bounties) on the platform.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): the utility is described directly in the whitepaper.
  • Conflict note (if any): —

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

  • TK_2 (decision): 0
  • Claim (one line): the reward economy is described as points→airdrop, but onchain staking/slashing/collateral are not described in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): there are incentives via the airdrop promise, but no protocol‑level staking/slashing mechanisms.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): governance with the FIR token is not described in the extracted Tier‑1.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): the whitepaper lists the utilities, but governance is not singled out.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the key AI functions (music generation) can work without the token; the token is mainly for the economy/monetization/promo.
  • Evidence: Tier‑1 — https://fireverse-ventures.gitbook.io/white-paper
  • Why sufficient / why not (one line): the whitepaper describes the platform and the token utility, but does not show that the core functions are impossible without FIR.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://fireverse-ventures.gitbook.io/white-paper description of the product, the AI component, token utility, allocations/vesting, roadmap, team/investors.
Tier‑1 https://bscscan.com/token/0x238d72e179a581c98dc1996417a49818c7e509dc the FIR contract, max total supply of 1B and the basic properties of the token.
Tier‑1 — Tier‑1 sources with addresses/audits of the smart contracts for copyright/revenue distribution were not found / not confirmed by Tier‑1.

No comments to display

Back to top