Skip to main content

Venice Token

Venice Token (VVV) — 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).

Venice.ai describes itself as a private and “uncensored” alternative to ChatGPT and provides AI inference via an app and an API (text/image/code generation). The VVV token on Base is used as a stake‑based access key to a share of the total inference capacity of the Venice API without “per request” payment.

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 app and API for text/image/code generation with an emphasis on privacy and “uncensored” modes.
  • Who it’s for: users, developers and AI agents that need inference capacity via an API.
  • Why onchain/token: the VVV token is used as a stake key that grants the right to consume a proportional share of the Venice API’s AI capacity (instead of paying for each request); the onchain layer is the Base ERC‑20 token (and staking/transfer operations).
  • What you can actually touch (Tier‑1): the Venice web app (chat/images/code) and Venice API examples in the docs.

How it works (very briefly)

  1. The user does: uses the Venice app or the Venice API for text/code/images; optionally stakes VVV.
  2. The system does: returns AI responses via the API/app; when VVV is staked, grants a daily inference limit as a pro‑rata share of the total “capacity” (per the project’s claim).
  3. The user gets: inference without “per request” payment (within the limit), plus a potential staking yield (emissions).
  4. Where the blockchain is: the VVV token is issued as an ERC‑20 on Base; transfers/staking/emissions are tied to onchain operations.
  5. Token role: stake‑based access to inference capacity + emissions yield; the project explicitly states that the token is not required to use the app/API (there are alternative payment/subscription modes).

Quick links: AI thesis fit

Project passport

Field Value
Project name Venice Token
Also known as (aliases) Venice.ai, VVV
Logo (logo) ../assets/venice_logo.webp
Token symbol (ticker) VVV
Category AI/Inference
Primary chain (chain) Base
Type EVM
Network status mainnet
Consensus (consensus) L2 (Optimistic Rollup, Base on Ethereum)
Launch date (launch_date) 2025-01-27
Project status (status) active
Token (standard) ERC-20
Token contract 0xacfe6019ed1a7dc6f7b508c02d1b04ec88cc21bf
Token model (token_type) utility (access + staking + emissions)
Max supply — (no hard cap; initial 100000000 at genesis)
Issuance inflationary (mint)
Tokenomics (tokenomics, brief) 100000000 at genesis; 14000000 minted annually (as claimed)
Governance company (no token governance)
Admins/keys owner can mint (single owner)
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) private uncensored inference API (text/image/code)
Use‑case (use_case) tokenized access to AI inference
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

Venice.ai is an AI product (app + API) for generative inference: text/image/code. The docs list API endpoints (chat completions, image generation, audio TTS, characters) and a model catalog. The project promotes privacy (no data retention) and the ability to use the API in the OpenAI style (by changing the base URL).

The VVV token adds a separate mode of consuming inference: instead of “per request” payment, one can stake VVV and receive proportional access to the total capacity of the Venice API (as claimed in the official post). At the same time, the project separately emphasizes that using the token is not mandatory.

Features/modules

  • Venice API: chat completions, image generation/editing, audio TTS, “characters” API.
  • Staking‑based access via VVV: stake as an “access key” to a share of the total inference capacity (limit/day).
  • Changelog/Roadmap: a public feed of updates and a roadmap via Featurebase.

Typical scenarios

  • Scenario 1 (regular user): uses the app/subscription → sends requests to models → receives responses/images.
  • Scenario 2 (developer/agent): integrates the Venice API (OpenAI‑compatible approach) → receives inference.
  • Scenario 3 (VVV staker): stakes VVV → receives a daily inference limit as a share of capacity + emissions yield (per the project’s claim).

Getting started (wallet/network)

  • What you need: an API key (for developers) and/or an account; for staking — an EVM wallet on Base.
  • Network/chain: Base (VVV — ERC‑20 on Base).
  • Fees: Base gas for token/staking operations; the product also has alternative payment/subscription modes.

Architecture/tech (non‑AI)

  • Components: app + Venice API; the onchain VVV token.
  • Where logic runs: inference/routing — offchain (API); token accounting and its transfer/mint — onchain (Base).

Token/economics (expanded, no forecasts)

  • Purpose of VVV: staking grants the right to consume a pro‑rata share of inference capacity without per‑request payment (up to a daily limit).
  • Issuance: the official post states “14m new VVV are created each year” (inflation decreases over time).
  • Contract: BaseScan shows that the token is a simple ERC‑20 with mint() under onlyOwner (no hard cap in the code).
  • Governance: the post explicitly states “No governance”.

Governance

According to the project, no token governance is provided (“No governance”), and the token contract has an owner role for mint.

Security and incidents

  • Security advisories: the repository’s public advisories page exists, but no advisories have been published.
  • Audits: there is a public Trust Security audit page for Venice.ai (report details/audit scope are not disclosed on the page).
  • Bug bounty: not found in Tier‑1 sources.

Project status and timeline

  • Current status: the VVV token and the product are active; the changelog is updated regularly.
  • Token launch: the post “Introducing the Venice token: VVV” is dated 2025‑01‑27.

Ecosystem/integrations

  • Integrations: the docs contain guides for AI agents and compatibility with the OpenAI SDK (changing the base URL).
  • Community: Discord/X in links_*.

AI component of the project

  • What is real AI here? Venice provides AI inference via an API: text/image/code generation (models are listed in the docs).
  • What is truly onchain? Tier‑1 shows the onchain VVV token on Base; the inference logic is offchain (API), while the token stake is used as an access key (described in the official post).
  • Why is a token needed? VVV is needed to “stake → receive a share of inference capacity without per‑request payment” and to receive an emissions yield; at the same time, the token is not required to use the service (there are alternative ways).
  • Red flags (based on the information found): onchain‑washing (addresses/specification of the actual staking mechanism are needed), token‑washing (check where the token is actually required), centralization risk (owner mint).

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 a real product component (API inference), not just a roadmap intent.
  • Evidence: Tier‑1 — https://docs.venice.ai/
  • Why sufficient / why not (one line): the docs describe the API and models (a working product), so AI_0 is not needed.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): the Venice API provides chat completions (text), image generation and other endpoints for generative inference.
  • Evidence: Tier‑1 — https://docs.venice.ai/
  • Why sufficient / why not (one line): the docs list the API capabilities (chat, images, audio, characters).
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): the docs contain examples of API calls (including OpenAI‑compatible examples).
  • Evidence: Tier‑1 — https://docs.venice.ai/
  • Why sufficient / why not (one line): there are code samples of requests.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://docs.venice.ai/
  • Why sufficient / why not (one line): there are no reproducible quality metrics/benchmarks in Tier‑1 sources.
  • Conflict note (if any): —

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

  • AI_4 (decision): 0
  • Claim (one line): there is a list of models/API parameters, but no technical description of a proprietary AI architecture/model versions as “protocol‑level AI”.
  • Evidence: Tier‑1 — https://docs.venice.ai/
  • Why sufficient / why not (one line): the docs focus on consuming models via the API, not on model architecture.
  • Conflict note (if any): —

Onchain necessity

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

  • OC_1 (decision): 1
  • Chain: Base Mainnet
  • Addresses/identifiers: VVV ERC‑20: 0xacfE6019Ed1A7Dc6f7B508C02d1b04ec88cC21bf
  • Evidence: Tier‑1 — https://basescan.org/token/0xacfE6019Ed1A7Dc6f7B508C02d1b04ec88cC21bf
  • Why sufficient / why not (one line): the token contract and supply/owner are observable on BaseScan.
  • Conflict note (if any): —

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

  • OC_2 (decision): 0
  • What useful logic is onchain: the available Tier‑1 sources contain no specific addresses/contracts of the staking mechanics (other than the token).
  • Evidence: Tier‑1 — https://venice.ai/blog/introducing-the-venice-token-vvv
  • Why sufficient / why not (one line): the post describes staking as an access concept, but without verifiable onchain addresses of staking contracts.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: based on Tier‑1, it cannot be proven that the product “breaks down” without the blockchain (inference is available as a regular API/subscription).
  • Evidence: Tier‑1 — https://venice.ai/blog/introducing-the-venice-token-vvv
  • Why sufficient / why not (one line): the post emphasizes that the token is not required.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the VVV token exists (ERC‑20 on Base).
  • Evidence: Tier‑1 — https://basescan.org/token/0xacfE6019Ed1A7Dc6f7B508C02d1b04ec88cC21bf
  • Why sufficient / why not (one line): BaseScan shows the contract, symbol and supply.
  • 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): the VVV model is stake‑based access to capacity, not “payment for each request”.
  • Evidence: Tier‑1 — https://venice.ai/blog/introducing-the-venice-token-vvv
  • Why sufficient / why not (one line): the post explicitly contrasts “pay per request” with “stake → infer for free (up to a limit)”.
  • Conflict note (if any): —

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

  • TK_2 (decision): 1
  • Claim (one line): stakers receive an emissions‑based yield; emissions are described as part of the mechanics.
  • Evidence: Tier‑1 — https://venice.ai/blog/introducing-the-venice-token-vvv
  • Why sufficient / why not (one line): the tokenomics describe annual emissions and their distribution to stakers.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 0
  • Claim (one line): there is no token governance (“No governance”).
  • Evidence: Tier‑1 — https://venice.ai/blog/introducing-the-venice-token-vvv
  • Why sufficient / why not (one line): a direct statement in the post.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 1
  • Claim (one line): the token model is described as optional; the app/API can be used without the token.
  • Evidence: Tier‑1 — https://venice.ai/blog/introducing-the-venice-token-vvv
  • Why sufficient / why not (one line): the post emphasizes “no new requirement to use the token”.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.venice.ai/ the existence of a working AI product (API), its capabilities (chat/images/audio/characters) and call examples
Tier‑1 https://venice.ai/blog/introducing-the-venice-token-vvv the purpose of VVV: stake‑based access to inference capacity, tokenomics (100m genesis, 14m/year), “No governance”, the token is not required
Tier‑1 https://basescan.org/token/0xacfE6019Ed1A7Dc6f7B508C02d1b04ec88cC21bf the VVV contract on Base, symbol, supply, verified source (including mint() under owner)
Tier‑1 https://veniceai.featurebase.app/changelog the existence of a public changelog (an artifact of product support/development)
Tier‑1 https://github.com/veniceai/api-docs/security/advisories the existence of a security advisories page (no advisories published at the time of verification)
Tier‑1 https://www.trust-security.xyz/venice-ai-audit The existence of a public page of the auditor Trust Security for Venice.ai (report details/audit scope are not disclosed on the page).

No comments to display

Back to top