Skip to main content

DeepCave

DeepCave — 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).

DeepCave — an AI/Other project on Ethereum, token (symbol: CAVE).

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 AI‑based platform/service for generating images from text (text‑to‑image) (claimed on the website and in the whitepaper).
  • Who it’s for: users/creators of digital content (images/NFT) who need a generation interface (claimed).
  • Why onchain/token: the CAVE token is described as the ecosystem’s utility+governance token (whitepaper); an ERC‑20 token on Ethereum is confirmed onchain.
  • What you can actually touch (Tier‑1): a Telegram bot for generation (see links_*).

How it works (very briefly)

  1. The user does: describes the desired image in text (prompt) and sends a request (for example, via the Telegram bot).
  2. The system does: generates an image using an AI model (claimed).
  3. The user gets: the generated result (image).
  4. Where the blockchain is: the CAVE token on the Ethereum network is confirmed onchain; the role of the blockchain in content storage/trading is described in the whitepaper (requires further validation against addresses/contracts).
  5. Token role: in the whitepaper, the token is described as a means of access/exchange on the platform and governance+staking mechanics.

Quick links: AI thesis fit

Project passport

Field Value
Project name DeepCave
Also known as (aliases) DeepCave AI, CAVE
Logo (logo) ../assets/777_deepcave_logo.png
Token symbol (ticker) CAVE
Category AI/Other | Consumer
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x63f3795f332be0b27580EDB6b33613CF4E5a7C30
Token model (token_type) utility (payments + staking + governance)
Max supply 98 000 000 CAVE
Issuance —
Tokenomics (tokenomics, brief) The whitepaper describes utility/governance and staking mechanics (details require validation against contracts).
Governance —
Admins/keys —
Audit yes
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) text-to-image generation
Use‑case (use_case) content generation + digital assets
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 1 / token_score 3 / evidence_score 3
Last verified 2026-02-11

General project overview

DeepCave describes itself as a service for generating images from text (text‑to‑image). In the Tier‑1 whitepaper, the project links AI content generation with blockchain infrastructure and describes the role of the token in the ecosystem. No Tier‑1 list of specific onchain contracts of the platform (other than the token) was found, so the onchain part beyond the token is recorded conservatively.

Features/modules

  • Text‑to‑image AI: image generation from a text description (Tier‑1).
  • Telegram demo surface: a bot through which generation can be tried (Tier‑1).

Typical scenarios

  • Scenario 1: a user sends a prompt → receives a generated image.
  • Scenario 2: a user interacts with the CAVE token (transfers/DEX) → operations are visible onchain.

Getting started (wallet/network)

  • What you need: Telegram to use the demo surface; an Ethereum wallet for onchain operations with the token.
  • Network/chain: Ethereum mainnet.
  • Fees: Ethereum network fees for transactions.

Architecture/tech (non‑AI)

  • Components: an AI generation service (offchain), the CAVE token (onchain).
  • Participant roles: users, service/infrastructure operators, Ethereum providers.
  • Where logic runs: offchain — generation; onchain — the token and related operations.
  • Dependencies: Ethereum infrastructure.

Token/economics (expanded, no forecasts)

  • Token utility: in the whitepaper, the token is described as a means of exchange on the platform and as a governance token; a staking mechanism is also described (details require verification against contracts/parameters).
  • Supply parameters: max total supply 98 000 000 CAVE (onchain).
  • Who pays fees: users (gas in ETH) for transactions.
  • Where fees go: to Ethereum network validators/stakers (within the network mechanics).
  • Issuance/burn: —.

Governance

  • Who makes decisions: described as governance via the token (whitepaper), but process details are not established per Tier‑1.
  • How protocol parameters change: —.
  • Where decisions are discussed/made: —.
  • Keys/multisig: —.

Security and incidents

  • Audits: a public audit is claimed (see links_* / Evidence).
  • Bug bounty: not found per Tier‑1.
  • Incidents: —.
  • Threat model: risks of the token smart contracts and offchain service; details of the platform’s onchain components are needed.

Project status and timeline

  • Current status: token on Ethereum mainnet; the demo surface is available via Telegram.
  • Key releases/milestones: —.
  • Roadmap: —.

Ecosystem/integrations

  • Integrations: Telegram demo surface (see links_*).
  • Partners: —.
  • Where it’s actually used: not established per Tier‑1 (other than the described demo surface).

AI component of the project

  • What is real AI here? AI image generation from a text description (Tier‑1 website + whitepaper).
  • What is truly onchain? The CAVE ERC‑20 token on the Ethereum network.
  • Why is a token needed? In the whitepaper, the token is described as a utility/governance token, including a staking mechanism; the practical necessity of the token for all platform features requires additional validation.
  • Red flags (based on the information found): AI model quality metrics are absent; the platform’s onchain components (other than the token) are not confirmed by addresses/contracts per Tier‑1.

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity low 1
Token necessity high 3
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 an operating feature (text‑to‑image), not only intent.
  • Evidence: Tier‑1 — https://deepcave.io/
  • Why sufficient / why not (one line): There is a Tier‑1 description of features and a demo surface.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): AI generates images from a text description (text‑to‑image).
  • Evidence: Tier‑1 — https://deepcave.io/ ; https://deepcave.io/whitepaper/
  • Why sufficient / why not (one line): Tier‑1 sources directly describe the purpose of the AI part.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): There is a Telegram bot for generation (“Start Creating”).
  • Evidence: Tier‑1 — https://t.me/deepcaveAi
  • Why sufficient / why not (one line): The presence of a demo surface.
  • 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 Tier‑1 model quality benchmark/metrics were found.
  • Conflict note (if any): —

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

  • AI_4 (decision): 1
  • Claim (one line): The whitepaper describes AI algorithms and the general technical context (training/generation).
  • Evidence: Tier‑1 — https://deepcave.io/whitepaper/
  • Why sufficient / why not (one line): There is a Tier‑1 tech description at the whitepaper level.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Ethereum
  • Addresses/identifiers: CAVE ERC‑20 token contract: 0x63f3795f332be0b27580EDB6b33613CF4E5a7C30
  • Evidence: Tier‑1 — https://etherscan.io/token/0x63f3795f332be0b27580EDB6b33613CF4E5a7C30
  • Why sufficient / why not (one line): The token contract and supply parameters are verifiable onchain.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: not established per Tier‑1 (other than the token).
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): The whitepaper describes onchain aspects, but the platform’s addresses/contracts (other than the token) are not recorded.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: not established.
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): There is no Tier‑1 justification of onchain criticality for the core generation feature.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): The project has a CAVE ERC‑20 token on the Ethereum network.
  • Evidence: Tier‑1 — https://etherscan.io/token/0x63f3795f332be0b27580EDB6b33613CF4E5a7C30
  • Why sufficient / why not (one line): The existence of the token is verifiable onchain.
  • 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): In the whitepaper, the token is described as a means of exchange on the platform (purchase/exchange of digital content).
  • Evidence: Tier‑1 — https://deepcave.io/whitepaper/
  • Why sufficient / why not (one line): There is a Tier‑1 claim about the payment function in the ecosystem.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): The whitepaper describes a staking mechanism and reward model for token holders.
  • Evidence: Tier‑1 — https://deepcave.io/whitepaper/
  • Why sufficient / why not (one line): There is a Tier‑1 description of incentives via staking.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): The token is described as a governance token with voting on proposals.
  • Evidence: Tier‑1 — https://deepcave.io/whitepaper/
  • Why sufficient / why not (one line): A direct Tier‑1 claim about the governance role.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): The replaceability of the token without loss of the claimed features (exchange/staking/governance) is not established.
  • Evidence: Tier‑1 — https://deepcave.io/whitepaper/
  • Why sufficient / why not (one line): Additional implementation details are needed to confidently assert replaceability.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://deepcave.io/ Product purpose: text‑to‑image AI generation (claimed).
Tier‑1 https://deepcave.io/whitepaper/ Tier‑1 whitepaper: the AI part, the role of the blockchain and token (utility/governance/staking) (claimed).
Tier‑1 https://t.me/deepcaveAi Demo surface: a Telegram bot for generation.
Tier‑1 https://etherscan.io/token/0x63f3795f332be0b27580EDB6b33613CF4E5a7C30 Onchain facts: the CAVE token, Ethereum network, contract, max supply.
Tier‑1 https://github.com/Coinsult/solidity/blob/main/Coinsult_Deepcave_0xBc...fD5D_Audit.pdf Public audit (Coinsult).
Tier‑2 https://coinmarketcap.com/currencies/deepcave/ Aggregator profile (for reference).